{ "corpus": "orca-core", "version": "v1", "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": [ "apple-pay:rail.apple-pay", "au-npp:rail.au-npp", "au-npp-reject:rail.au-npp-reject", "bancontact:rail.bancontact", "blik:rail.blik", "boleto:rail.boleto", "eps:rail.eps", "eps-error:rail.eps-error", "eps-refund-error:rail.eps-refund-error", "eps-status-reason:rail.eps-status-reason", "google-pay:rail.google-pay", "in-upi:rail.in-upi", "mx-spei:rail.mx-spei", "pix:rail.pix", "rtp-reject:rail.rtp-reject", "uk-fps:rail.uk-fps", "uk-fps-reject:rail.uk-fps-reject", "uk-fps-return:rail.uk-fps-return", "us-ach:rail.us-ach" ], "classes": [ "Rail", "Role", "TransactionType", "Exception", "ReasonCode", "Rule", "RuleSource", "Mandate", "LifecycleState", "Calendar", "Message", "Field", "CodeSet", "Instrument" ], "relation_types": { "raised_in": [ { "from": [ "ReasonCode" ], "to": [ "Exception" ] } ], "returned_by": [ { "from": [ "ReasonCode" ], "to": [ "Role" ] } ], "governed_by": [ { "from": [ "ReasonCode" ], "to": [ "Rule" ] }, { "from": [ "Exception" ], "to": [ "Rule" ] }, { "from": [ "Mandate" ], "to": [ "Rule" ] }, { "from": [ "LifecycleState" ], "to": [ "Rule" ] } ], "counts_toward": [ { "from": [ "ReasonCode" ], "to": [ "Rule" ] } ], "applies_to": [ { "from": [ "ReasonCode" ], "to": [ "TransactionType" ] }, { "from": [ "Rule" ], "to": [ "TransactionType" ] }, { "from": [ "Rule" ], "to": [ "Instrument" ] }, { "from": [ "Field" ], "to": [ "TransactionType" ] } ], "concerns": [ { "from": [ "ReasonCode" ], "to": [ "Mandate" ] } ], "sourced_from": [ { "from": [ "Rule", "Role", "TransactionType", "Exception", "Rail", "Mandate", "LifecycleState", "Calendar", "Message", "Field", "CodeSet", "Instrument" ], "to": [ "RuleSource" ] } ], "binds": [ { "from": [ "Rule" ], "to": [ "Role" ] } ], "part_of": [ { "from": [ "Rule" ], "to": [ "Exception" ] }, { "from": [ "Message" ], "to": [ "Message" ] } ], "supersedes": [ { "from": [ "Rule" ], "to": [ "Rule" ] }, { "from": [ "CodeSet" ], "to": [ "CodeSet" ] } ], "initiated_by": [ { "from": [ "Exception" ], "to": [ "Role" ] } ], "decided_by": [ { "from": [ "Exception" ], "to": [ "Role" ] } ], "follows": [ { "from": [ "Exception" ], "to": [ "Exception" ] } ], "enters": [ { "from": [ "Exception" ], "to": [ "LifecycleState" ] } ], "precedes": [ { "from": [ "LifecycleState" ], "to": [ "LifecycleState" ] } ], "counted_on": [ { "from": [ "Rule" ], "to": [ "Calendar" ] } ], "about": [ { "from": [ "Rule" ], "to": [ "Message", "Field" ] } ], "takes_values": [ { "from": [ "Field" ], "to": [ "CodeSet" ] } ], "uses": [ { "from": [ "TransactionType" ], "to": [ "Instrument" ] } ], "given_by": [ { "from": [ "Mandate" ], "to": [ "Role" ] } ], "given_to": [ { "from": [ "Mandate" ], "to": [ "Role" ] } ], "authorises": [ { "from": [ "Mandate" ], "to": [ "TransactionType", "Instrument" ] } ], "derived_from": [ { "from": [ "Mandate" ], "to": [ "Mandate" ] } ], "revoked_via": [ { "from": [ "Mandate" ], "to": [ "Rule" ] } ], "evidenced_by": [ { "from": [ "Mandate" ], "to": [ "Rule" ] } ], "disputed_via": [ { "from": [ "Mandate" ], "to": [ "Exception" ] } ], "defers_to": [ { "from": [ "any" ], "to": [ "rail-fact", "Rule", "Rail" ] } ], "see_also": [ { "from": [ "any" ], "to": [ "any" ] } ] }, "records": [ { "uid": "apple-pay:rail.apple-pay", "id": "rail.apple-pay", "class": "Rail", "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", "operators": [ "Apple Payments Services LLC, a subsidiary of Apple Inc., which provides Apple Pay in the United States; the Apple affiliate providing Apple Pay differs by location, and neither Apple Inc. nor the affiliate is a bank (Apple Pay and privacy notice; support article 118270)" ], "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" ], "relations": [ { "type": "sourced_from", "to": "apple-pay:src.developer-program-license-agreement", "section": "3.3.9(C) and the definitions of Apple Pay APIs, Apple Pay Payload, Intermediary Party and Merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "apple-pay:src.acceptable-use-guidelines-web", "section": "whole page", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "apple-pay:src.apple-pay-privacy-notice", "section": "whole page", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:participants", "note": "The payment is a card payment; the Visa facts hold the network layer.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:participants", "note": "The payment is a card payment; the Mastercard facts hold the network layer.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "google-pay:rail.google-pay", "note": "The other pass-through wallet in the corpus, under the same brief.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "used_by": [ { "from": "google-pay:rail.google-pay", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "apple-pay:exc.apple-disables-apple-pay-on-a-site", "id": "exc.apple-disables-apple-pay-on-a-site", "rail": "apple-pay", "class": "Exception", "name": "Apple disables Apple Pay on a website", "summary": "Apple stops Apple Pay transactions on a business's website. The acceptable use guidelines reserve this to Apple at any time and for any reason Apple deems prudent, so no ground has to be shown and the prohibited-use list is not the limit of it.", "money_moves": false, "outcome": "Apple Pay stops being available on that site. The guidelines give no notice period, no procedure and no route of review, and none was found in the pages read [Unverified]. Payments already made are not affected by the wallet; anything already authorised is the card network's business.", "relations": [ { "type": "initiated_by", "to": "apple-pay:role.wallet-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "apple-pay:role.wallet-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "apple-pay:rule.apple-may-disable-on-a-site", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "apple-pay:rule.prohibited-website-uses", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "apple-pay:src.acceptable-use-guidelines-web", "section": "Prohibited Uses, closing sentence", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Acceptable Use Guidelines for Apple Pay on the Web, read in full 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "Unknown: the guidelines carry no date", "effective_to": null, "effective_note": "Drafted 2026-09-20. The page carries no date and no version, so when this text took effect cannot be given [Unverified]. A person re-reads the page each quarter; the monthly watch does not fetch Apple's sites.", "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": "apple-pay:src.acceptable-use-guidelines-web", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms Apple's reserved right to disable Apple Pay transactions on a website at any time for any reason it deems prudent." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:rule.apple-may-disable-on-a-site", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.no-staged-wallet-behind-apple-pay", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.prohibited-website-uses", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "apple-pay:exc.merchant-ignores-the-transaction", "id": "exc.merchant-ignores-the-transaction", "rail": "apple-pay", "class": "Exception", "name": "Merchant ignores the transaction after a failed token check", "summary": "The merchant or its payment processor checks an Apple Pay payment token and the check fails: the signature does not verify, a hash does not match, the signing time is more than five minutes from the transaction time so the token may be a replay, a payment with the same transaction identifier is already processed, or the currency, amount or application data do not match the original payment request.", "money_moves": false, "outcome": "The merchant ignores the transaction, which the reference states twice as the outcome of a failed check. Nothing is presented to the card network, so the payment does not happen. The reference sets no message back to Apple or to the cardholder, and none was found [Unverified].", "relations": [ { "type": "initiated_by", "to": "apple-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "apple-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "apple-pay:rule.signature-and-decryption-checks", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "apple-pay:rule.token-signing-time-five-minutes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "apple-pay:rule.duplicate-transaction-id-check", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "apple-pay:rule.merchant-verifies-then-processes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "apple-pay:src.payment-token-format-reference", "section": "steps 1, 5, 6 and 7", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Payment token format reference, steps 1 to 7, read in full 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "Unknown: the reference carries no date", "effective_to": null, "effective_note": "Drafted 2026-09-20. The reference carries no date or version, so when this text took effect cannot be given [Unverified].", "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": "apple-pay:src.payment-token-format-reference", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the merchant ignores an Apple Pay transaction where the signature is invalid, a hash does not match, the signing time exceeds the five minute window, the transaction identifier is already processed, or transaction validation otherwise fails." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:rule.duplicate-transaction-id-check", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.merchant-verifies-then-processes", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.signature-and-decryption-checks", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.token-signing-time-five-minutes", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "apple-pay:exc.merchant-refund-to-card", "id": "exc.merchant-refund-to-card", "rail": "apple-pay", "class": "Exception", "name": "Merchant refund to the card used in Apple Pay", "summary": "A merchant returns money for an Apple Pay purchase. The merchant's own refund policy decides whether and how, and the merchant may need the last four digits of the Apple Pay card number, which differ from the physical card's, or may ask the cardholder to authenticate and hold the device to the contactless reader.", "money_moves": true, "outcome": "The refund goes back to the payment card automatically once the merchant processes it, and may take several days to appear on the card statement. The refund itself runs on the card network, whose rules Orca holds in the visa and mastercard refund facts; Apple publishes no refund mechanism of its own.", "relations": [ { "type": "initiated_by", "to": "apple-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "apple-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "apple-pay:rule.merchant-refunds-to-the-card", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "apple-pay:rule.device-account-number-differs-from-the-card", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "apple-pay:src.support-118270-refunds", "section": "whole article", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "visa:refund", "note": "The refund runs on the card network.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:refund", "note": "The refund runs on the card network.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Support article 118270, read in full 2026-09-20. It is Apple's consumer guidance, not a rule binding the merchant, so it says what happens rather than what must happen.", "confidence": "medium" }, "currency": { "effective_since": "2025-05-29", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the published date the article states; the article may have been revised since without the date changing [Unverified].", "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": "apple-pay:src.support-118270-refunds", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms a merchant refunding an Apple Pay purchase may need the Apple Pay card number's last four digits, or may ask the cardholder to authenticate and hold the device to a contactless reader." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:rule.device-account-number-differs-from-the-card", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.merchant-refunds-to-the-card", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "apple-pay:role.acquirer", "id": "role.acquirer", "rail": "apple-pay", "class": "Role", "name": "Acquirer (the merchant's bank for card payments)", "summary": "The bank or processor through which the merchant presents the card payment. The Developer Program License Agreement names it as one of the parties the payment actually runs between, alongside the merchant's bank, the card networks and any other party the merchant uses for transaction processing, and it makes the merchant responsible for complying with those agreements. Apple has no agreement with it over the payment.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.developer-program-license-agreement", "section": "3.3.9(C)(i), not a party clause", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Developer Program License Agreement 3.3.9(C)(i); read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2026-08-18", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the public copy of the agreement. The date is the last-updated date its own footer gives for the Agreement and Schedule 1. The provision may be older, and when it first applied was not traced [Unverified]. The binding version is the one a developer accepts in its account, which Orca cannot read.", "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": "apple-pay:src.developer-program-license-agreement", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the acquirer is named among the parties the payment runs between under the developer's own agreements, outside any Apple agreement." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:rule.merchant-processes-through-its-own-chain", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "apple-pay:role.card-issuer", "id": "role.card-issuer", "rail": "apple-pay", "class": "Role", "name": "Card issuer", "summary": "The bank or other institution that offers the card the cardholder adds to Wallet. It decides, with the payment network, whether a card can be set up in Apple Pay and what further verification a cardholder must pass, and it or the network approves and generates the merchant-specific account number used for recurring and merchant-initiated charges. Its cardholder agreement keeps governing the card in Apple Pay, and it, not Apple, decides the payment.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.apple-pay-privacy-notice", "section": "setting up Apple Pay; merchant-specific account numbers; closing paragraph", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "apple-pay:src.support-118270-refunds", "section": "closing paragraph", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Apple Pay and privacy notice; support article 118270; read 2026-09-20. That the issuer rather than Apple decides the payment follows from the not a party clause of the Developer Program License Agreement read with the notice [Inference].", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the notice carries no date", "effective_to": null, "effective_note": "Drafted 2026-09-20. The notice carries no date or version, so when this text took effect cannot be given [Unverified].", "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": "apple-pay:src.apple-pay-privacy-notice", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the card issuer's part in setting up a card in Apple Pay, approving further verification, and approving or generating merchant-specific account numbers for recurring charges." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:rule.issuer-and-network-decide-provisioning", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.merchant-token-for-recurring-charges", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "apple-pay:role.card-network", "id": "role.card-network", "rail": "apple-pay", "class": "Role", "name": "Card network (payment network)", "summary": "The network the card runs on. Apple's notice calls it the payment network. It shares in deciding whether a card is eligible for Apple Pay, may add an ECI indicator to the payment token that the merchant must pass on, and approves or generates merchant-specific account numbers with the issuer. Its rulebook, not Apple's terms, governs authorisation, clearing, settlement, disputes and liability for the payment; Orca holds those rules in the visa and mastercard rails.", "kind": "operator", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.apple-pay-privacy-notice", "section": "setting up Apple Pay; merchant-specific account numbers", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "apple-pay:src.payment-token-format-reference", "section": "detailed payment data keys (3D Secure), eciIndicator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:participants", "note": "Visa's own rules for the network layer.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:participants", "note": "Mastercard's own rules for the network layer.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Apple Pay and privacy notice; payment token format reference; read 2026-09-20. No Visa or Mastercard document was read for this rail; what the network rules say is held in the visa and mastercard rails and linked, not restated.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the notice carries no date", "effective_to": null, "effective_note": "Drafted 2026-09-20. The notice carries no date or version, so when this text took effect cannot be given [Unverified].", "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": "apple-pay:src.apple-pay-privacy-notice", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the payment network's part in setting up a card in Apple Pay and in approving or generating merchant-specific account numbers together with the issuer." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:rule.issuer-and-network-decide-provisioning", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.merchant-token-for-recurring-charges", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "apple-pay:role.cardholder", "id": "role.cardholder", "rail": "apple-pay", "class": "Role", "name": "Cardholder (the end user)", "summary": "The person who holds a credit, debit or prepaid card, adds it to Wallet and authorises a payment with it. Apple calls this party the end user. The card is offered by the card issuer, and the cardholder's agreement with the issuer keeps governing its use in Apple Pay. Before any payment the cardholder authenticates on the device.", "kind": "party", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.apple-pay-privacy-notice", "section": "who provides Apple Pay; terms that keep governing", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "apple-pay:src.support-118270-refunds", "section": "closing paragraph", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "apple-pay:src.apple-pay-developer-overview", "section": "Data is more secure", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Apple Pay and privacy notice; support article 118270; 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. The notice carries no date or version, so when this text took effect cannot be given [Unverified].", "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": "apple-pay:src.apple-pay-developer-overview", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the cardholder authenticates on the device before every Apple Pay payment." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:rule.card-and-merchant-terms-keep-governing", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.cardholder-authenticates-before-every-payment", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.device-account-number-differs-from-the-card", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.no-wallet-dispute-channel", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "apple-pay:role.intermediary-party", "id": "role.intermediary-party", "rail": "apple-pay", "class": "Role", "name": "Intermediary party", "summary": "A party that passes an end user's Apple Pay Payload to a merchant so the payment can be processed outside the application, or that supplies an application letting merchants take Tap to Pay payments or run customer engagement interactions. The Developer Program License Agreement gives it its own duties over the payload, makes it tell end users it is an intermediary and name the merchant on the payment sheet, and makes it answerable to Apple for the merchant it chooses.", "kind": "service_provider", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.developer-program-license-agreement", "section": "definitions, Intermediary Party; 3.3.9(C)(ii)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Developer Program License Agreement, the definition of Intermediary Party and section 3.3.9(C)(ii); read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2026-08-18", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the public copy of the agreement. The date is the last-updated date its own footer gives for the Agreement and Schedule 1. The provision may be older, and when it first applied was not traced [Unverified]. The binding version is the one a developer accepts in its account, which Orca cannot read.", "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": "apple-pay:src.developer-program-license-agreement", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the intermediary party's duties over the Apple Pay Payload, including disclosure to end users and naming the merchant on the payment sheet." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:rule.intermediary-party-duties", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "apple-pay:role.merchant", "id": "role.merchant", "rail": "apple-pay", "class": "Role", "name": "Merchant", "summary": "The party that processes Apple Pay payment transactions and sells the goods or services. That is the first limb of the agreement's definition of Merchant; its other limbs cover parties using the Tap to Pay, identity verification and customer engagement interfaces, which are outside this rail. A merchant may use the Apple Pay Payload to process the transaction and for other uses it has disclosed to the end user, within the law. Apple is not a party to that payment: it runs between the merchant and the merchant's own bank, acquirer and card networks.", "kind": "party", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.developer-program-license-agreement", "section": "definitions, Merchant, limb (a); 3.3.9(C)(i) and (ii)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Developer Program License Agreement, the definition of Merchant and section 3.3.9(C); read 2026-09-20. Only limb (a) of the definition is used; the rest of the definition is about interfaces this rail does not cover.", "confidence": "high" }, "currency": { "effective_since": "2026-08-18", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the public copy of the agreement. The date is the last-updated date its own footer gives for the Agreement and Schedule 1. The provision may be older, and when it first applied was not traced [Unverified]. The binding version is the one a developer accepts in its account, which Orca cannot read.", "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": "apple-pay:src.developer-program-license-agreement", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the merchant processes the payment transaction and sells the goods or services, and that Apple is not a party to that payment." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:exc.merchant-ignores-the-transaction", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:exc.merchant-ignores-the-transaction", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:exc.merchant-refund-to-card", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:exc.merchant-refund-to-card", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.apple-cash-and-balance-transfers", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.apple-is-not-a-party", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.card-and-merchant-terms-keep-governing", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.device-account-number-differs-from-the-card", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.display-parity-and-primary-option", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.duplicate-transaction-id-check", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.eci-indicator-must-be-passed-on", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.merchant-key-and-payload-security", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.merchant-never-sees-the-card-number", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.merchant-processes-through-its-own-chain", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.merchant-refunds-to-the-card", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.merchant-use-of-the-payload", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.merchant-verifies-then-processes", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.no-staged-wallet-behind-apple-pay", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.prohibited-website-uses", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.signature-and-decryption-checks", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.token-signing-time-five-minutes", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.what-the-apis-may-be-used-for", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "apple-pay:role.wallet-operator", "id": "role.wallet-operator", "rail": "apple-pay", "class": "Role", "name": "Wallet operator (Apple Payments Services LLC and the other Apple affiliates)", "summary": "The Apple affiliate that provides Apple Pay. In the United States it is Apple Payments Services LLC, a subsidiary of Apple Inc.; the provider differs by location. Neither Apple Inc. nor the affiliate providing Apple Pay is a bank. For the Apple Pay API terms of the Developer Program License Agreement, Apple means Apple Payments Services LLC where the developer is in the United States. The operator sets conduct rules for developers and websites, re-encrypts the credential for the merchant, and may disable Apple Pay on a website; it takes no part in authorising, clearing or settling the payment.", "kind": "service_provider", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.apple-pay-privacy-notice", "section": "who provides Apple Pay; closing paragraph", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "apple-pay:src.developer-program-license-agreement", "section": "3.3.9(C), closing sentence", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "apple-pay:src.support-118270-refunds", "section": "closing paragraph", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Apple Pay and privacy notice; Developer Program License Agreement 3.3.9(C); support article 118270; read 2026-09-20. That the operator takes no part in authorisation, clearing or settlement is the not a party clause of 3.3.9(C)(i) read with the privacy notice; the card networks' own definition of a pass-through wallet was not read for this rail.", "confidence": "high" }, "currency": { "effective_since": "2026-08-18", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the public copy of the agreement. The date is the last-updated date its own footer gives for the Agreement and Schedule 1. The provision may be older, and when it first applied was not traced [Unverified]. The binding version is the one a developer accepts in its account, which Orca cannot read.", "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": "apple-pay:src.apple-pay-privacy-notice", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the Apple affiliate providing Apple Pay differs by location, is Apple Payments Services LLC in the United States, and that neither it nor Apple Inc. is a bank." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:exc.apple-disables-apple-pay-on-a-site", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:exc.apple-disables-apple-pay-on-a-site", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.apple-is-not-a-party", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.apple-may-disable-on-a-site", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.apple-reencrypts-the-credential", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.merchant-never-sees-the-card-number", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.who-provides-apple-pay-and-is-not-a-bank", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "apple-pay:role.web-view-host", "id": "role.web-view-host", "rail": "apple-pay", "class": "Role", "name": "Web view host (a party that only displays the merchant checkout page)", "summary": "A party that shows a merchant's checkout page through a web view while being neither the merchant nor an intermediary party. It may not access the Apple Pay Payload at all, and it may not use anything derived from or relating to the payment for any purpose beyond displaying that page. It is the third recipient the Developer Program License Agreement addresses, and the only one barred from the payload outright.", "kind": "service_provider", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.developer-program-license-agreement", "section": "3.3.9(C)(ii), third case", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Developer Program License Agreement 3.3.9(C)(ii); read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2026-08-18", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the public copy of the agreement. The date is the last-updated date its own footer gives for the Agreement and Schedule 1. The provision may be older, and when it first applied was not traced [Unverified]. The binding version is the one a developer accepts in its account, which Orca cannot read.", "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": "apple-pay:src.developer-program-license-agreement", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the web view host may not access the Apple Pay Payload and may use payment-related information only to display the merchant's page." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:rule.web-view-host-may-not-touch-the-payload", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "apple-pay:rule.apple-cash-and-balance-transfers", "id": "rule.apple-cash-and-balance-transfers", "rail": "apple-pay", "class": "Rule", "name": "Apple Cash as an option, and moving a stored balance to a provisioned card", "statement": "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.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.developer-program-license-agreement", "section": "3.3.9(C)(i), fourth and fifth bullets", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "apple-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Developer Program License Agreement 3.3.9(C)(i), read 2026-09-20. Apple Cash itself is a stored-value product outside this rail; the duty to offer it is a rule on an Apple Pay API user, so it is recorded here.", "confidence": "high" }, "currency": { "effective_since": "2026-08-18", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the public copy of the agreement. The date is the last-updated date its own footer gives for the Agreement and Schedule 1. The provision may be older, and when it first applied was not traced [Unverified]. The binding version is the one a developer accepts in its account, which Orca cannot read.", "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": "apple-pay:src.developer-program-license-agreement", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the developer's duty to include Apple Cash as a payment option where available and the right to use the Apple Pay APIs to move stored end user balances to provisioned cards." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "apple-pay:rule.apple-is-not-a-party", "id": "rule.apple-is-not-a-party", "rail": "apple-pay", "class": "Rule", "name": "Apple is not a party to the payment and is not responsible for it", "statement": "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.", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.developer-program-license-agreement", "section": "3.3.9(C)(i), not a party clause, and the closing sentence of 3.3.9(C)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "apple-pay:role.wallet-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "apple-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "apple-pay:txn.in-app-and-web", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:finality", "note": "Whether the payment is final is the network's rule.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:finality", "note": "Whether the payment is final is the network's rule.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Developer Program License Agreement 3.3.9(C)(i), read 2026-09-20. The last sentence of the statement, that nothing in the wallet decides finality, reversal or loss, is what the clause means read with the rest of 3.3.9(C) [Inference]; the card networks' own definitions of a pass-through wallet were not read for this rail.", "confidence": "high" }, "currency": { "effective_since": "2026-08-18", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the public copy of the agreement. The date is the last-updated date its own footer gives for the Agreement and Schedule 1. The provision may be older, and when it first applied was not traced [Unverified]. The binding version is the one a developer accepts in its account, which Orca cannot read.", "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": "apple-pay:src.developer-program-license-agreement", "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, is not responsible for it or for an unavailable card or payment fraud, and that the payment runs between the developer and its bank, acquirer and card networks." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "apple-pay:rule.apple-may-disable-on-a-site", "id": "rule.apple-may-disable-on-a-site", "rail": "apple-pay", "class": "Rule", "name": "Apple may disable Apple Pay on a website at any time", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.acceptable-use-guidelines-web", "section": "Prohibited Uses, closing sentence", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "apple-pay:role.wallet-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "apple-pay:exc.apple-disables-apple-pay-on-a-site", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Acceptable Use Guidelines for Apple Pay on the Web, read in full 2026-09-20. That there is no notice, procedure or review is an absence in the page, not a statement in it [Inference].", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the guidelines carry no date", "effective_to": null, "effective_note": "Drafted 2026-09-20. The page carries no date and no version, so when this text took effect cannot be given [Unverified]. A person re-reads the page each quarter; the monthly watch does not fetch Apple's sites.", "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": "apple-pay:src.acceptable-use-guidelines-web", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms Apple's reserved right to disable Apple Pay transactions on a website at any time for any reason it deems prudent, with no notice, procedure or review stated on the page." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:exc.apple-disables-apple-pay-on-a-site", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "apple-pay:rule.apple-reencrypts-the-credential", "id": "rule.apple-reencrypts-the-credential", "rail": "apple-pay", "class": "Rule", "name": "Apple re-encrypts the credential so only the merchant side can read it", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.apple-pay-privacy-notice", "section": "transmitting payment information in apps, websites and Business Chat", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "apple-pay:role.wallet-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "apple-pay:txn.in-app-and-web", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:settlement", "note": "Clearing and settlement are the network's.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:settlement", "note": "Clearing and settlement are the network's.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Apple Pay and privacy notice, read 2026-09-20. That Apple does not carry the money is the not a party clause of the Developer Program License Agreement read with this passage [Inference].", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the notice carries no date", "effective_to": null, "effective_note": "Drafted 2026-09-20. The notice carries no date or version, so when this text took effect cannot be given [Unverified].", "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": "apple-pay:src.apple-pay-privacy-notice", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms payment information sent to Apple in apps, websites and Business Chat is briefly decrypted and re-encrypted with a merchant-specific key, and that a Mac unable to hold a card communicates with the authorising device through Apple's servers." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "apple-pay:rule.card-and-merchant-terms-keep-governing", "id": "rule.card-and-merchant-terms-keep-governing", "rail": "apple-pay", "class": "Rule", "name": "The card, cardholder and merchant agreements keep governing", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.apple-pay-privacy-notice", "section": "closing paragraph", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "apple-pay:role.cardholder", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "apple-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:consumer-law", "note": "The card's own rules and the law that reaches them.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:consumer-law", "note": "The card's own rules and the law that reaches them.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Apple Pay and privacy notice, closing paragraph, read 2026-09-20. No consumer law was read for this rail.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the notice carries no date", "effective_to": null, "effective_note": "Drafted 2026-09-20. The notice carries no date or version, so when this text took effect cannot be given [Unverified].", "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": "apple-pay:src.apple-pay-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 the cards and their use in Apple Pay and that Apple's notice is in addition to a bank's own notices." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "apple-pay:rule.cardholder-authenticates-before-every-payment", "id": "rule.cardholder-authenticates-before-every-payment", "rail": "apple-pay", "class": "Rule", "name": "The cardholder authenticates on the device before every payment", "statement": "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.", "rests_on": "guidance", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.apple-pay-developer-overview", "section": "Data is more secure", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "apple-pay:role.cardholder", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:liability", "note": "What authentication is worth in a dispute is the network's rule.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:liability", "note": "What authentication is worth in a dispute is the network's rule.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa-dispute:10.1", "note": "A counterfeit fraud dispute condition.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa-dispute:10.2", "note": "A dispute condition for a contactless transaction.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa-dispute:10.4", "note": "A card-absent fraud dispute condition.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Apple Pay developer overview, read 2026-09-20. It is a developer marketing and description page, so it rests on guidance. Apple Platform Security, which describes the mechanism, was not read. What the linked Visa conditions require is held in those records and is not restated here.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the page carries no date", "effective_to": null, "effective_note": "Drafted 2026-09-20. The page carries no date or version, so when this text took effect cannot be given [Unverified].", "source_edition": "Apple Pay developer overview page, undated, 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": "apple-pay:src.apple-pay-developer-overview", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms every iPhone or iPad transaction requires Face ID, Touch ID or a passcode and that an Apple Watch requires its passcode again each time it is removed." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "apple-pay:rule.decrypted-payment-data-fields", "id": "rule.decrypted-payment-data-fields", "rail": "apple-pay", "class": "Rule", "name": "What the decrypted payment data carries", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.payment-token-format-reference", "section": "payment data keys; authentication response", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "applies_to", "to": "apple-pay:txn.in-app-and-web", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Payment token format reference, read in full 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "Unknown: the reference carries no date", "effective_to": null, "effective_note": "Drafted 2026-09-20. The reference carries no date or version, so when this text took effect cannot be given [Unverified].", "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": "apple-pay:src.payment-token-format-reference", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the decrypted payment data keys: device-specific account number, expiration date as YYMMDD, ISO 4217 numeric currency code, amount, optional cardholder name, device manufacturer identifier, payment data type, multitoken authentication responses, and merchant token identifier and metadata." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "apple-pay:rule.detailed-payment-data-3dsecure-and-emv", "id": "rule.detailed-payment-data-3dsecure-and-emv", "rail": "apple-pay", "class": "Rule", "name": "The two detailed payment data forms, 3D Secure and EMV", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.payment-token-format-reference", "section": "detailed payment data keys (3D Secure); detailed payment data keys (EMV)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "applies_to", "to": "apple-pay:txn.in-app-and-web", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "apple-pay:txn.in-store-contactless", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Payment token format reference, read in full 2026-09-20. Which channel produces which form is not stated on the page; the pairing of EMV with an in-store tap is not asserted here [Unverified].", "confidence": "high" }, "currency": { "effective_since": "Unknown: the reference carries no date", "effective_to": null, "effective_note": "Drafted 2026-09-20. The reference carries no date or version, so when this text took effect cannot be given [Unverified].", "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": "apple-pay:src.payment-token-format-reference", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the 3D Secure detailed payment data carries an online payment cryptogram and an optional ECI indicator, and the EMV form carries the Secure Element's EMV structure with an encrypted PIN for RSA_v1 only." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "apple-pay:rule.device-account-number-differs-from-the-card", "id": "rule.device-account-number-differs-from-the-card", "rail": "apple-pay", "class": "Rule", "name": "The Apple Pay card number is not the card's number, which matters for refunds", "statement": "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.", "rests_on": "guidance", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.support-118270-refunds", "section": "Find your Apple Pay card number; Get a refund to a payment card that you use with Apple Pay", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "apple-pay:src.apple-pay-privacy-notice", "section": "paying in apps and on the web", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "apple-pay:role.cardholder", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "apple-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "apple-pay:exc.merchant-refund-to-card", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Support article 118270; Apple Pay and privacy notice; read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "2025-05-29", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the published date the article states; the article may have been revised since without the date changing [Unverified].", "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": "apple-pay:src.support-118270-refunds", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the Apple Pay card number differs from the physical card number, that a merchant may use it or ask for its last four digits to process a refund, and how the cardholder finds it in Wallet." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:exc.merchant-refund-to-card", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "apple-pay:rule.display-parity-and-primary-option", "id": "rule.display-parity-and-primary-option", "rail": "apple-pay", "class": "Rule", "name": "Display parity, and Apple Pay as the primary option where a card is provisioned", "statement": "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.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.acceptable-use-guidelines-web", "section": "Apple Pay APIs; Design", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "apple-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Acceptable Use Guidelines for Apple Pay on the Web, read in full 2026-09-20. The marketing and human interface guidelines the page points at were not read, so what they require is unknown here.", "confidence": "high" }, "currency": { "effective_since": "2026-09-20", "effective_to": null, "effective_note": "Drafted 2026-09-20. The page carries no date and no version, so when this text took effect cannot be given [Unverified]. A person re-reads the page each quarter; the monthly watch does not fetch Apple's sites. The limits facet has to carry an ISO effective_since and the page carries no date, so the date is the day the page was read; it dates the reading, not the rule, and when the rule took effect is unknown [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": "apple-pay:src.acceptable-use-guidelines-web", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the display parity duty for a page that takes other third-party payment methods and the duty to present Apple Pay as the primary option once an active card is detected." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "apple-pay:rule.duplicate-transaction-id-check", "id": "rule.duplicate-transaction-id-check", "rail": "apple-pay", "class": "Rule", "name": "A repeated transaction identifier means the payment was already credited", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.payment-token-format-reference", "section": "step 5; header keys and values, transactionId", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "apple-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "apple-pay:txn.in-app-and-web", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "apple-pay:exc.merchant-ignores-the-transaction", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Payment token format reference, step 5 and the header table, read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the reference carries no date", "effective_to": null, "effective_note": "Drafted 2026-09-20. The reference carries no date or version, so when this text took effect cannot be given [Unverified].", "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": "apple-pay:src.payment-token-format-reference", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the merchant's duty to check that no payment with the same transaction identifier already shows as processed, looking within the five minute window of the current transaction time." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:exc.merchant-ignores-the-transaction", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "apple-pay:rule.eci-indicator-must-be-passed-on", "id": "rule.eci-indicator-must-be-passed-on", "rail": "apple-pay", "class": "Rule", "name": "An ECI indicator in the token must be passed on unchanged", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.payment-token-format-reference", "section": "detailed payment data keys (3D Secure), eciIndicator", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "apple-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "apple-pay:txn.in-app-and-web", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:liability", "note": "What an ECI value means for liability is the network's rule.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:liability", "note": "What an ECI value means for liability is the network's rule.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Payment token format reference, read 2026-09-20. The last sentence marks the boundary; no network document was read for this rail.", "confidence": "high" }, "currency": { "effective_since": "Unknown: the reference carries no date", "effective_to": null, "effective_note": "Drafted 2026-09-20. The reference carries no date or version, so when this text took effect cannot be given [Unverified].", "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": "apple-pay:src.payment-token-format-reference", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms that where an ECI indicator is present the merchant must pass it on to its payment processor or the transaction fails." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "apple-pay:rule.intermediary-party-duties", "id": "rule.intermediary-party-duties", "rail": "apple-pay", "class": "Rule", "name": "What an intermediary party owes", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.developer-program-license-agreement", "section": "3.3.9(C)(ii), second case, items (a) to (e); definitions, Intermediary Party", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "apple-pay:role.intermediary-party", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Developer Program License Agreement 3.3.9(C)(ii) and the definition of Intermediary Party, read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2026-08-18", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the public copy of the agreement. The date is the last-updated date its own footer gives for the Agreement and Schedule 1. The provision may be older, and when it first applied was not traced [Unverified]. The binding version is the one a developer accepts in its account, which Orca cannot read.", "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": "apple-pay:src.developer-program-license-agreement", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the duties on a party acting as an intermediary party over the Apple Pay Payload, including limited use, no combination with other data, disclosure to end users and responsibility for a merchant it uses." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "apple-pay:rule.issuer-and-network-decide-provisioning", "id": "rule.issuer-and-network-decide-provisioning", "rail": "apple-pay", "class": "Rule", "name": "The issuer and the payment network decide whether a card goes into the wallet", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.apple-pay-privacy-notice", "section": "setting up Apple Pay; adding a card from a third-party app; feature eligibility; closing paragraph", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "apple-pay:role.card-issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "apple-pay:role.card-network", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:decision-points", "note": "Provisioning duties on issuers are the network's rules.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:decision-points", "note": "Provisioning duties on issuers are the network's rules.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Apple Pay and privacy notice, read in full 2026-09-20. The notice describes data flows; that the decision itself is the issuer's and the network's is what those flows are for, as the notice states them [Inference].", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the notice carries no date", "effective_to": null, "effective_note": "Drafted 2026-09-20. The notice carries no date or version, so when this text took effect cannot be given [Unverified].", "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": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "apple-pay:rule.merchant-key-and-payload-security", "id": "rule.merchant-key-and-payload-security", "rail": "apple-pay", "class": "Rule", "name": "Keys are held securely and payment data is never decrypted on the device", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.developer-program-license-agreement", "section": "3.3.9(C)(i), second bullet", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "apple-pay:src.payment-token-format-reference", "section": "step 2", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "apple-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Developer Program License Agreement 3.3.9(C)(i); payment token format reference, step 2; read 2026-09-20. The last sentence joins the agreement's bar on device decryption to the reference's step 2 [Inference].", "confidence": "high" }, "currency": { "effective_since": "2026-08-18", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the public copy of the agreement. The date is the last-updated date its own footer gives for the Agreement and Schedule 1. The provision may be older, and when it first applied was not traced [Unverified]. The binding version is the one a developer accepts in its account, which Orca cannot read.", "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": "apple-pay:src.developer-program-license-agreement", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the developer's duty to hold private keys securely, not to store end user payment information unencrypted on an iPhone or iPad, and not to decrypt it there." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "apple-pay:rule.merchant-never-sees-the-card-number", "id": "rule.merchant-never-sees-the-card-number", "rail": "apple-pay", "class": "Rule", "name": "The merchant does not receive the card number", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.apple-pay-developer-overview", "section": "Data is more secure", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "apple-pay:src.apple-pay-privacy-notice", "section": "paying in apps and on the web; setting up Apple Pay", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "apple-pay:src.payment-token-format-reference", "section": "payment data keys, applicationPrimaryAccountNumber", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "apple-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "apple-pay:role.wallet-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Apple Pay developer overview; Apple Pay and privacy notice; payment token format reference; read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "Unknown: the reference carries no date", "effective_to": null, "effective_note": "Drafted 2026-09-20. The reference carries no date or version, so when this text took effect cannot be given [Unverified].", "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": "apple-pay:src.apple-pay-developer-overview", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms that a merchant accepting Apple Pay does not receive the customer's actual card number." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "apple-pay:rule.merchant-processes-through-its-own-chain", "id": "rule.merchant-processes-through-its-own-chain", "rail": "apple-pay", "class": "Rule", "name": "The merchant processes the payment through its own bank, acquirer and networks", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.developer-program-license-agreement", "section": "3.3.9(C)(i), not a party clause", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "apple-pay:src.apple-pay-developer-overview", "section": "Find a PSP that supports Apple Pay", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "apple-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "apple-pay:role.acquirer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:settlement", "note": "How the money actually settles is the network's rule.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:settlement", "note": "How the money actually settles is the network's rule.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Developer Program License Agreement 3.3.9(C)(i); Apple Pay developer overview; read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2026-08-18", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the public copy of the agreement. The date is the last-updated date its own footer gives for the Agreement and Schedule 1. The provision may be older, and when it first applied was not traced [Unverified]. The binding version is the one a developer accepts in its account, which Orca cannot read.", "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": "apple-pay:src.developer-program-license-agreement", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the payment runs between the developer and its own bank, acquirer, card networks and other processing parties, and that Apple supplies none of that processing." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "apple-pay:rule.merchant-refunds-to-the-card", "id": "rule.merchant-refunds-to-the-card", "rail": "apple-pay", "class": "Rule", "name": "A refund is the merchant's, and it goes back to the card", "statement": "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.", "rests_on": "guidance", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.support-118270-refunds", "section": "opening paragraphs", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "apple-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "apple-pay:exc.merchant-refund-to-card", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:refund", "note": "How a refund reaches the card is the network's rule.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:refund", "note": "How a refund reaches the card is the network's rule.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Support article 118270, read in full 2026-09-20. It is Apple's consumer guidance, not a rule binding merchants, so it rests on guidance.", "confidence": "medium" }, "currency": { "effective_since": "2025-05-29", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the published date the article states; the article may have been revised since without the date changing [Unverified].", "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": "apple-pay:src.support-118270-refunds", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms that returning an Apple Pay purchase follows the merchant's own policy, that a receipt is generally enough, and that a processed refund goes back to the card automatically and may take days to appear." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:exc.merchant-refund-to-card", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "apple-pay:rule.merchant-token-for-recurring-charges", "id": "rule.merchant-token-for-recurring-charges", "rail": "apple-pay", "class": "Rule", "name": "A merchant-specific account number stands behind recurring and merchant-initiated charges", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.apple-pay-privacy-notice", "section": "recurring and merchant-initiated charges", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "apple-pay:src.payment-token-format-reference", "section": "payment data keys, merchantTokenIdentifier and merchantTokenMetadata", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "apple-pay:role.card-issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "apple-pay:role.card-network", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Apple Pay and privacy notice; payment token format reference; read 2026-09-20. How a merchant token is revoked, disputed or expires was not read, so no Mandate is drafted and the known gaps say so.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the notice carries no date", "effective_to": null, "effective_note": "Drafted 2026-09-20. The notice carries no date or version, so when this text took effect cannot be given [Unverified].", "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": "apple-pay:src.apple-pay-privacy-notice", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the issuer or payment network approves and generates a merchant-specific account number for recurring or merchant-initiated charges, that only that number can authorise such a charge, and that Apple knows the merchant involved but not the purchase." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "apple-pay:rule.merchant-use-of-the-payload", "id": "rule.merchant-use-of-the-payload", "rail": "apple-pay", "class": "Rule", "name": "What a merchant may do with the Apple Pay Payload", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.developer-program-license-agreement", "section": "3.3.9(C)(ii), opening and first case; definitions, Apple Pay Payload", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "apple-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Developer Program License Agreement 3.3.9(C)(ii) and the definition of Apple Pay Payload, read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2026-08-18", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the public copy of the agreement. The date is the last-updated date its own footer gives for the Agreement and Schedule 1. The provision may be older, and when it first applied was not traced [Unverified]. The binding version is the one a developer accepts in its account, which Orca cannot read.", "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": "apple-pay:src.developer-program-license-agreement", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms a party acting as the merchant may use the Apple Pay Payload to process the payment and for other uses it discloses to the end user, within the law." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "apple-pay:rule.merchant-verifies-then-processes", "id": "rule.merchant-verifies-then-processes", "rail": "apple-pay", "class": "Rule", "name": "The merchant checks the transaction details, then either processes or ignores it", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.payment-token-format-reference", "section": "steps 1, 6 and 7", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "apple-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "apple-pay:exc.merchant-ignores-the-transaction", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Payment token format reference, steps 1, 6 and 7, read in full 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the reference carries no date", "effective_to": null, "effective_note": "Drafted 2026-09-20. The reference carries no date or version, so when this text took effect cannot be given [Unverified].", "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": "apple-pay:src.payment-token-format-reference", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the merchant's verification of currency code, amount and application data against the original request before processing, and that it ignores the transaction otherwise." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:exc.merchant-ignores-the-transaction", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "apple-pay:rule.no-staged-wallet-behind-apple-pay", "id": "rule.no-staged-wallet-behind-apple-pay", "rail": "apple-pay", "class": "Rule", "name": "A staged wallet may not sit behind Apple Pay", "statement": "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.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.acceptable-use-guidelines-web", "section": "Prohibited Uses, staged digital wallet item", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "apple-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "apple-pay:exc.apple-disables-apple-pay-on-a-site", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "paypal:participants", "note": "A staged wallet is the other family; Orca holds PayPal as its own rail.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Acceptable Use Guidelines for Apple Pay on the Web, read in full 2026-09-20. The last sentence states what the rule is for, drawn from the two cases the guidelines name [Inference].", "confidence": "high" }, "currency": { "effective_since": "2026-09-20", "effective_to": null, "effective_note": "Drafted 2026-09-20. The page carries no date and no version, so when this text took effect cannot be given [Unverified]. A person re-reads the page each quarter; the monthly watch does not fetch Apple's sites. The limits facet has to carry an ISO effective_since and the page carries no date, so the date is the day the page was read; it dates the reading, not the rule, and when the rule took effect is unknown [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": "apple-pay:src.acceptable-use-guidelines-web", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the prohibition on a staged digital wallet, defined as a second payment completing the first or a substitute merchant of record." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "apple-pay:rule.no-wallet-dispute-channel", "id": "rule.no-wallet-dispute-channel", "rail": "apple-pay", "class": "Rule", "name": "Apple publishes no dispute channel of its own for a merchant purchase", "statement": "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.", "rests_on": "guidance", "facet": "return", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.support-118270-refunds", "section": "whole article", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "apple-pay:src.apple-pay-privacy-notice", "section": "closing paragraph", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "apple-pay:src.developer-program-license-agreement", "section": "3.3.9(C)(i), not a party clause", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "apple-pay:role.cardholder", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:return", "note": "The dispute rules for the payment are Visa's.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:return", "note": "The dispute rules for the payment are Mastercard's.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa-dispute:10.4", "note": "A card-absent fraud dispute, the condition a wallet payment in an app or on the web falls under.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa-dispute:13.1", "note": "A merchandise or services not received dispute, which is about the sale and not the wallet.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "apple-pay:rule.no-wallet-recall", "note": "The other absence, from the same Apple pages. That record is about recalling or cancelling a completed payment; this one is about disputing it. A wallet could publish one route and not the other, so the two absences are separate claims.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Support article 118270; Apple Pay and privacy notice; Developer Program License Agreement 3.3.9(C)(i); read 2026-09-20. This is a claim that nothing exists on the pages read; Apple's wider consumer support site was not read [Unverified]. What the linked Visa conditions require is held in those records and is not restated here.", "confidence": "medium" }, "currency": { "effective_since": "2025-05-29", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the published date the article states; the article may have been revised since without the date changing [Unverified].", "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": "apple-pay:src.support-118270-refunds", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms Apple's published consumer guidance after an Apple Pay purchase covers only merchant refunds and offers no route to dispute or reverse the payment." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:rule.no-wallet-recall", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "apple-pay:rule.no-wallet-recall", "id": "rule.no-wallet-recall", "rail": "apple-pay", "class": "Rule", "name": "Apple publishes no way to recall or cancel a completed payment", "statement": "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.", "rests_on": "guidance", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.support-118270-refunds", "section": "whole article", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "apple-pay:src.developer-program-license-agreement", "section": "3.3.9(C)(i), not a party clause", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:recall", "note": "Where a card payment can be recalled, the rule is the network's.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:recall", "note": "Where a card payment can be recalled, the rule is the network's.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "apple-pay:rule.no-wallet-dispute-channel", "note": "The other absence, from the same Apple pages. That record is about disputing a payment and points at the card networks' dispute conditions; this one is about recalling or cancelling a completed payment. A wallet could publish one route and not the other, so the two absences are separate claims.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Support article 118270 and Developer Program License Agreement 3.3.9(C)(i), read 2026-09-20. This is a claim that nothing exists, drawn from reading the pages that were saved and finding no such route [Inference]. Apple's consumer support pages beyond article 118270 were not read, so the claim is that no route was published on these pages, not that none exists anywhere [Unverified].", "confidence": "medium" }, "currency": { "effective_since": "2025-05-29", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the published date the article states; the article may have been revised since without the date changing [Unverified].", "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": "apple-pay:src.support-118270-refunds", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms Apple's published consumer guidance offers no route to recall, cancel or reverse a completed Apple Pay card payment." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:rule.no-wallet-dispute-channel", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "apple-pay:rule.payment-token-structure", "id": "rule.payment-token-structure", "rail": "apple-pay", "class": "Rule", "name": "The structure of an Apple Pay payment token", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.payment-token-format-reference", "section": "Overview; payment token structure; header keys and values", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "applies_to", "to": "apple-pay:txn.in-app-and-web", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:messages", "note": "The authorisation message the merchant then sends is the network's.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:messages", "note": "The authorisation message the merchant then sends is the network's.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Payment token format reference, read in full 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "Unknown: the reference carries no date", "effective_to": null, "effective_note": "Drafted 2026-09-20. The reference carries no date or version, so when this text took effect cannot be given [Unverified].", "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": "apple-pay:src.payment-token-format-reference", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the payment token's four keys, the EC_v1 and RSA_v1 versions, and the header fields." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "apple-pay:rule.prohibited-website-uses", "id": "rule.prohibited-website-uses", "rail": "apple-pay", "class": "Rule", "name": "The classes of website and trade that may not use Apple Pay", "statement": "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.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.acceptable-use-guidelines-web", "section": "Prohibited Uses", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "apple-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "apple-pay:exc.apple-disables-apple-pay-on-a-site", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Acceptable Use Guidelines for Apple Pay on the Web, Prohibited Uses, read in full 2026-09-20. The classes are Apple's; the grouping and order here are Orca's, and the list is the guidelines' own and not exhaustive of what Apple may act on, since Apple reserves disabling for any reason it deems prudent.", "confidence": "high" }, "currency": { "effective_since": "2026-09-20", "effective_to": null, "effective_note": "Drafted 2026-09-20. The page carries no date and no version, so when this text took effect cannot be given [Unverified]. A person re-reads the page each quarter; the monthly watch does not fetch Apple's sites. The limits facet has to carry an ISO effective_since and the page carries no date, so the date is the day the page was read; it dates the reading, not the rule, and when the rule took effect is unknown [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": "apple-pay:src.acceptable-use-guidelines-web", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the listed classes of website that may not incorporate Apple Pay." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:exc.apple-disables-apple-pay-on-a-site", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "apple-pay:rule.signature-and-decryption-checks", "id": "rule.signature-and-decryption-checks", "rail": "apple-pay", "class": "Rule", "name": "The checks a merchant runs on a payment token before it decrypts", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.payment-token-format-reference", "section": "steps 1 to 4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "apple-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "apple-pay:exc.merchant-ignores-the-transaction", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Payment token format reference, steps 1 to 4, read in full 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "Unknown: the reference carries no date", "effective_to": null, "effective_note": "Drafted 2026-09-20. The reference carries no date or version, so when this text took effect cannot be given [Unverified].", "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": "apple-pay:src.payment-token-format-reference", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the merchant's signature verification steps, the required certificate object identifiers, the Apple Root CA G3 chain of trust, and the decryption algorithms for EC_v1 and RSA_v1." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:exc.merchant-ignores-the-transaction", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "apple-pay:rule.token-signing-time-five-minutes", "id": "rule.token-signing-time-five-minutes", "rail": "apple-pay", "class": "Rule", "name": "A token signed more than five minutes from the transaction time may be a replay", "statement": "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.", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.payment-token-format-reference", "section": "step 1, last bullet", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "apple-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "apple-pay:txn.in-app-and-web", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "apple-pay:exc.merchant-ignores-the-transaction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:hours", "note": "The hours that matter for the payment are the network's.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:hours", "note": "The hours that matter for the payment are the network's.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Payment token format reference, step 1, read 2026-09-20. The five minutes is not carried in a typed time window: the schema's smallest unit is an hour, so the figure lives in this statement (logged as a Core finding).", "confidence": "high" }, "currency": { "effective_since": "Unknown: the reference carries no date", "effective_to": null, "effective_note": "Drafted 2026-09-20. The reference carries no date or version, so when this text took effect cannot be given [Unverified].", "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": "apple-pay:src.payment-token-format-reference", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the merchant checks the signature's signing time under RFC 5652 section 11.3 and treats a difference of more than five minutes from the transaction time as a possible replay." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:exc.merchant-ignores-the-transaction", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "apple-pay:rule.web-view-host-may-not-touch-the-payload", "id": "rule.web-view-host-may-not-touch-the-payload", "rail": "apple-pay", "class": "Rule", "name": "A party that only shows the checkout page may not touch the payload", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.developer-program-license-agreement", "section": "3.3.9(C)(ii), third case, items (a) and (b)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "apple-pay:role.web-view-host", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Developer Program License Agreement 3.3.9(C)(ii), read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2026-08-18", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the public copy of the agreement. The date is the last-updated date its own footer gives for the Agreement and Schedule 1. The provision may be older, and when it first applied was not traced [Unverified]. The binding version is the one a developer accepts in its account, which Orca cannot read.", "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": "apple-pay:src.developer-program-license-agreement", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms a party displaying a merchant's checkout page through a web view, acting as neither merchant nor intermediary party, may not access the Apple Pay Payload and may use payment-related information only to display that page." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "apple-pay:rule.what-the-apis-may-be-used-for", "id": "rule.what-the-apis-may-be-used-for", "rail": "apple-pay", "class": "Rule", "name": "What the Apple Pay APIs may be used for", "statement": "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.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.developer-program-license-agreement", "section": "3.3.9(C)(i), first paragraph and third bullet; the European Union, Japan and Brazil attachments", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "apple-pay:src.acceptable-use-guidelines-web", "section": "Apple Pay APIs", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "apple-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "apple-pay:txn.in-app-and-web", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Developer Program License Agreement 3.3.9(C)(i) and its regional attachments; Acceptable Use Guidelines for Apple Pay on the Web; read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2026-08-18", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the public copy of the agreement. The date is the last-updated date its own footer gives for the Agreement and Schedule 1. The provision may be older, and when it first applied was not traced [Unverified]. The binding version is the one a developer accepts in its account, which Orca cannot read.", "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": "apple-pay:src.developer-program-license-agreement", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the Apple Pay APIs may be used only to facilitate payments made by or through the application for goods and services used outside the device, and may not be called for unrelated purposes." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "apple-pay:rule.who-provides-apple-pay-and-is-not-a-bank", "id": "rule.who-provides-apple-pay-and-is-not-a-bank", "rail": "apple-pay", "class": "Rule", "name": "Who provides Apple Pay, and that the provider is not a bank", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "apple-pay:src.apple-pay-privacy-notice", "section": "who provides Apple Pay; closing paragraph", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "apple-pay:src.support-118270-refunds", "section": "closing paragraph", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "apple-pay:src.apple-pay-developer-overview", "section": "footer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "apple-pay:src.developer-program-license-agreement", "section": "3.3.9(C), closing sentence", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "apple-pay:role.wallet-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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. Three of the four are Apple's own statements about its own entity, which is as strong as a source for this gets.", "confidence": "high" }, "currency": { "effective_since": "2026-08-18", "effective_to": null, "effective_note": "Drafted 2026-09-20 from the public copy of the agreement. The date is the last-updated date its own footer gives for the Agreement and Schedule 1. The provision may be older, and when it first applied was not traced [Unverified]. The binding version is the one a developer accepts in its account, which Orca cannot read.", "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": "apple-pay:src.apple-pay-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 Inc. affiliates, that the provider differs by location and is Apple Payments Services LLC in the United States, and that neither Apple Inc. nor that affiliate is a bank." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "apple-pay:src.acceptable-use-guidelines-web", "id": "src.acceptable-use-guidelines-web", "rail": "apple-pay", "class": "RuleSource", "name": "Acceptable Use Guidelines for Apple Pay on the Web", "summary": "Apple's conduct rules for a business that puts Apple Pay on a website: the classes of website and trade that may not use it, Apple's right to disable Apple Pay on a site, the branding and interface guidelines a site must follow, the display parity duty where a page takes other third-party payment methods, and the limit that Apple Pay may be used only to enable or facilitate an Apple Pay transaction from that site.", "publisher": "Apple Inc.", "url": "https://developer.apple.com/apple-pay/acceptable-use-guidelines-for-websites/", "source_class": "authoritative_primary", "kind": "web_page", "edition": "Acceptable Use Guidelines for Apple Pay on the Web, undated page, read in full 2026-09-20 from the copy saved that day", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, opened and read on 2026-09-20 from the copy saved that day in the wallet source folder; its public URL is recorded above.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the guidelines carry no date", "effective_to": null, "effective_note": "Created 2026-09-20 for this rail. A RuleSource describes one edition of one document; its status stays draft and its consulted_on dates the reading.", "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": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:rail.apple-pay", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:exc.apple-disables-apple-pay-on-a-site", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:rule.apple-may-disable-on-a-site", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:rule.display-parity-and-primary-option", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:rule.no-staged-wallet-behind-apple-pay", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:rule.prohibited-website-uses", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:rule.what-the-apis-may-be-used-for", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "apple-pay:src.apple-pay-developer-overview", "id": "src.apple-pay-developer-overview", "rail": "apple-pay", "class": "RuleSource", "name": "Apple Pay developer overview page", "summary": "Apple's description for developers of what Apple Pay is and what accepting it means: payment in apps and on websites in Safari, authentication by Face ID, Touch ID, a passcode or a double click on Apple Watch, and the point that the merchant does not receive the customer's actual card numbers. It also states that Apple Pay is provided by certain Apple affiliates and that neither Apple nor its affiliates is a bank.", "publisher": "Apple Inc.", "url": "https://developer.apple.com/apple-pay/", "source_class": "public_primary", "kind": "web_page", "edition": "Apple Pay developer overview page, undated, read in full 2026-09-20 from the copy saved that day", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, opened and read on 2026-09-20 from the copy saved that day in the wallet source folder; its public URL is recorded above.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the page carries no date", "effective_to": null, "effective_note": "Created 2026-09-20 for this rail. A RuleSource describes one edition of one document; its status stays draft and its consulted_on dates the reading.", "source_edition": "Apple Pay developer overview page, undated, read in full 2026-09-20 from the copy saved that day", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:role.cardholder", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:rule.cardholder-authenticates-before-every-payment", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:rule.merchant-never-sees-the-card-number", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:rule.merchant-processes-through-its-own-chain", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.who-provides-apple-pay-and-is-not-a-bank", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:txn.in-app-and-web", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "apple-pay:src.apple-pay-privacy-notice", "id": "src.apple-pay-privacy-notice", "rail": "apple-pay", "class": "RuleSource", "name": "Apple Pay and privacy notice", "summary": "Apple's consumer notice on what data Apple Pay handles. It names the Apple entity that provides Apple Pay and says neither Apple nor that affiliate is a bank, says the card, cardholder and merchant agreements keep governing, describes the card issuer's and payment network's part in setting a card up, says the actual card number is not shared with the merchant, describes the merchant-specific account number used for recurring and merchant-initiated charges, and describes how the credential is re-encrypted so only the merchant, the developer or their payment processor can read it.", "publisher": "Apple Inc.", "url": "https://www.apple.com/legal/privacy/data/en/apple-pay/", "source_class": "public_primary", "kind": "web_page", "edition": "Apple Pay and privacy notice, undated page, read in full 2026-09-20 from the copy saved that day", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, opened and read on 2026-09-20 from the copy saved that day in the wallet source folder; its public URL is recorded above.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the notice carries no date", "effective_to": null, "effective_note": "Created 2026-09-20 for this rail. A RuleSource describes one edition of one document; its status stays draft and its consulted_on dates the reading.", "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": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:rail.apple-pay", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:role.card-issuer", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:role.card-network", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:role.cardholder", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:role.wallet-operator", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:rule.apple-reencrypts-the-credential", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:rule.card-and-merchant-terms-keep-governing", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:rule.device-account-number-differs-from-the-card", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.issuer-and-network-decide-provisioning", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.merchant-never-sees-the-card-number", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.merchant-token-for-recurring-charges", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:rule.no-wallet-dispute-channel", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.who-provides-apple-pay-and-is-not-a-bank", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:txn.in-app-and-web", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:txn.in-store-contactless", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "apple-pay:src.developer-program-license-agreement", "id": "src.developer-program-license-agreement", "rail": "apple-pay", "class": "RuleSource", "name": "Apple Developer Program License Agreement (public copy, Agreement and Schedule 1 last updated 2026-08-18)", "summary": "The agreement a member of the Apple Developer Program accepts. Section 3.3.9(C) governs the Apple Pay APIs: what an application may use them for, that Apple is not a party to the payment, how private keys and end user payment information must be held, and what the merchant, an intermediary party and a party that merely displays a merchant checkout page may do with the Apple Pay Payload. Its definitions section defines Apple Pay APIs, Apple Pay Payload, Intermediary Party and Merchant. Attachments for the European Union, Japan and Brazil vary 3.3.9(C) for alternative app marketplaces.", "publisher": "Apple Inc.", "url": "https://developer.apple.com/support/terms/apple-developer-program-license-agreement/", "source_class": "authoritative_primary", "kind": "web_page", "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", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, opened and read on 2026-09-20 from the copy saved that day in the wallet source folder; its public URL is recorded above.", "confidence": "medium" }, "currency": { "effective_since": "2026-08-18", "effective_to": null, "effective_note": "Created 2026-09-20 for this rail. A RuleSource describes one edition of one document; its status stays draft and its consulted_on dates the reading.", "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": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:rail.apple-pay", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:role.acquirer", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:role.intermediary-party", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:role.merchant", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:role.wallet-operator", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:role.web-view-host", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:rule.apple-cash-and-balance-transfers", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:rule.apple-is-not-a-party", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:rule.intermediary-party-duties", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:rule.merchant-key-and-payload-security", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:rule.merchant-processes-through-its-own-chain", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:rule.merchant-use-of-the-payload", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:rule.no-wallet-dispute-channel", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.no-wallet-recall", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.web-view-host-may-not-touch-the-payload", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:rule.what-the-apis-may-be-used-for", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:rule.who-provides-apple-pay-and-is-not-a-bank", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "apple-pay:src.payment-token-format-reference", "id": "src.payment-token-format-reference", "rail": "apple-pay", "class": "RuleSource", "name": "Payment token format reference (PassKit documentation)", "summary": "Apple's interface definition for the payment token a merchant receives and must check. It sets out the seven steps for verifying the signature, decrypting the payment data and validating the transaction, including the five minute replay window and the duplicate transaction check, and it tables every key of the payment token, its header, the decrypted payment data, the 3D Secure and EMV detailed payment data, and the authentication response entries.", "publisher": "Apple Inc.", "url": "https://developer.apple.com/documentation/passkit/payment-token-format-reference", "source_class": "authoritative_primary", "kind": "web_page", "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)", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, opened and read on 2026-09-20 from the copy saved that day in the wallet source folder; its public URL is recorded above.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the reference carries no date", "effective_to": null, "effective_note": "Created 2026-09-20 for this rail. A RuleSource describes one edition of one document; its status stays draft and its consulted_on dates the reading.", "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": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:exc.merchant-ignores-the-transaction", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:role.card-network", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.decrypted-payment-data-fields", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:rule.detailed-payment-data-3dsecure-and-emv", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:rule.duplicate-transaction-id-check", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:rule.eci-indicator-must-be-passed-on", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:rule.merchant-key-and-payload-security", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.merchant-never-sees-the-card-number", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.merchant-token-for-recurring-charges", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.merchant-verifies-then-processes", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:rule.payment-token-structure", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:rule.signature-and-decryption-checks", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:rule.token-signing-time-five-minutes", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:txn.in-app-and-web", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:txn.in-store-contactless", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "apple-pay:src.support-118270-refunds", "id": "src.support-118270-refunds", "rail": "apple-pay", "class": "RuleSource", "name": "Apple Support article 118270, Get a refund for purchases made with credit or debit cards using Apple Pay", "summary": "Apple's consumer guidance on refunds for an Apple Pay purchase from a merchant: the merchant's own policy decides, the refund goes back to the payment card and may take days to appear, the Apple Pay card number differs from the physical card number, where to find its last four digits in Wallet, and how to present the card at a contactless reader when the merchant needs it to process the refund.", "publisher": "Apple Inc.", "url": "https://support.apple.com/en-us/118270", "source_class": "public_primary", "kind": "web_page", "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", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, opened and read on 2026-09-20 from the copy saved that day in the wallet source folder; its public URL is recorded above.", "confidence": "medium" }, "currency": { "effective_since": "2025-05-29", "effective_to": null, "effective_note": "Created 2026-09-20 for this rail. A RuleSource describes one edition of one document; its status stays draft and its consulted_on dates the reading.", "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": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:exc.merchant-refund-to-card", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:role.card-issuer", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:role.cardholder", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:role.wallet-operator", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.device-account-number-differs-from-the-card", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:rule.merchant-refunds-to-the-card", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:rule.no-wallet-dispute-channel", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:rule.no-wallet-recall", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "apple-pay:rule.who-provides-apple-pay-and-is-not-a-bank", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:txn.in-store-contactless", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "apple-pay:txn.in-app-and-web", "id": "txn.in-app-and-web", "rail": "apple-pay", "class": "TransactionType", "name": "Apple Pay payment in an app or on the web", "summary": "A card-absent payment made in an iOS, iPadOS or watchOS app, on a website in Safari, or through Messages for Business and iMessage extensions. The cardholder authenticates on the device, and the merchant or its payment processor receives an Apple Pay payment token carrying a device-specific account number and, for the 3D Secure form, an online payment cryptogram and sometimes an ECI indicator. Apple re-encrypts the credential with a merchant-specific key on the way. It is a card payment on the card network; Apple is not a party to it.", "sec_code": null, "directions": [ "debit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "apple-pay:src.apple-pay-developer-overview", "section": "An easier way to pay within apps and websites; Data is more secure", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "apple-pay:src.payment-token-format-reference", "section": "payment data keys; detailed payment data keys (3D Secure)", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "apple-pay:src.apple-pay-privacy-notice", "section": "paying in apps and on the web", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:messages", "note": "The card-absent message layer is the network's.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:messages", "note": "The card-absent message layer is the network's.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Apple Pay developer overview; payment token format reference; Apple Pay and privacy notice; read 2026-09-20. sec_code is null: this is not an ACH rail and no scheme code names the type.", "confidence": "high" }, "currency": { "effective_since": "Unknown: the reference carries no date", "effective_to": null, "effective_note": "Drafted 2026-09-20. The reference carries no date or version, so when this text took effect cannot be given [Unverified].", "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": "apple-pay:src.apple-pay-developer-overview", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms Apple Pay is used to pay in apps, on websites in Safari, and in Messages for Business and iMessage extensions, with authentication on the device." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:rule.apple-is-not-a-party", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.apple-reencrypts-the-credential", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.decrypted-payment-data-fields", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.detailed-payment-data-3dsecure-and-emv", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.duplicate-transaction-id-check", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.eci-indicator-must-be-passed-on", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.payment-token-structure", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.token-signing-time-five-minutes", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "apple-pay:rule.what-the-apis-may-be-used-for", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "apple-pay:txn.in-store-contactless", "id": "txn.in-store-contactless", "rail": "apple-pay", "class": "TransactionType", "name": "Apple Pay payment in a store", "summary": "A payment made by holding the device to a contactless reader in a shop. The pages read for this rail confirm that in-store Apple Pay purchases happen and that a cardholder can present the card at a contactless reader for a merchant to process a refund, but none of them describes the in-store message or the contactless rules, which are the card network's. The Apple payment token's EMV form, carrying output from the Secure Element and an optionally encrypted PIN, is the in-device counterpart [Inference: the token reference does not say which channel uses which form].", "sec_code": null, "directions": [ "debit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "apple-pay:src.support-118270-refunds", "section": "Get a refund to a payment card that you use with Apple Pay", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "apple-pay:src.apple-pay-privacy-notice", "section": "purchases in stores and Apple Pay Merchant Identification", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "apple-pay:src.payment-token-format-reference", "section": "detailed payment data keys (EMV)", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:messages", "note": "The contactless rules for the payment are Visa's.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:messages", "note": "The contactless rules for the payment are Mastercard's.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Support article 118270; Apple Pay and privacy notice; payment token format reference; read 2026-09-20. Apple Platform Security, which describes the in-store flow, was not among the saved pages and was not read, so this type rests on passing mentions rather than a description [Unverified].", "confidence": "low" }, "currency": { "effective_since": "2025-05-29", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the published date the article states; the article may have been revised since without the date changing [Unverified].", "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": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:rule.detailed-payment-data-3dsecure-and-emv", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "apple-pay:rule.who-provides-apple-pay-and-is-not-a-bank", "apple-pay:rule.card-and-merchant-terms-keep-governing", "apple-pay:rule.apple-is-not-a-party", "apple-pay:rule.no-wallet-dispute-channel" ], "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.", "relations": [ { "type": "see_also", "to": "visa:consumer-law", "note": "The Visa rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:consumer-law", "note": "The Mastercard rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "google-pay:consumer-law", "note": "The same facet for the other pass-through wallet.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "apple-pay:src.apple-pay-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." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "google-pay:consumer-law", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "apple-pay:rule.issuer-and-network-decide-provisioning", "apple-pay:rule.cardholder-authenticates-before-every-payment", "apple-pay:rule.signature-and-decryption-checks", "apple-pay:rule.merchant-verifies-then-processes", "apple-pay:rule.duplicate-transaction-id-check", "apple-pay:rule.apple-may-disable-on-a-site", "apple-pay:rule.intermediary-party-duties" ], "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.", "relations": [ { "type": "see_also", "to": "visa:decision-points", "note": "The Visa rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:decision-points", "note": "The Mastercard rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "google-pay:decision-points", "note": "The same facet for the other pass-through wallet.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "google-pay:decision-points", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "apple-pay:rule.apple-is-not-a-party", "apple-pay:rule.merchant-processes-through-its-own-chain", "apple-pay:rule.merchant-verifies-then-processes", "apple-pay:rule.token-signing-time-five-minutes", "apple-pay:rule.duplicate-transaction-id-check", "apple-pay:rule.card-and-merchant-terms-keep-governing" ], "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.", "relations": [ { "type": "see_also", "to": "visa:finality", "note": "The Visa rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:finality", "note": "The Mastercard rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "google-pay:finality", "note": "The same facet for the other pass-through wallet.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "apple-pay:src.developer-program-license-agreement", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "google-pay:finality", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "apple-pay:rule.token-signing-time-five-minutes", "apple-pay:rule.duplicate-transaction-id-check", "apple-pay:rule.signature-and-decryption-checks" ], "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.", "relations": [ { "type": "see_also", "to": "visa:hours", "note": "The Visa rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:hours", "note": "The Mastercard rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "google-pay:hours", "note": "The same facet for the other pass-through wallet.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "apple-pay:src.payment-token-format-reference", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "google-pay:hours", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "apple-pay:rule.apple-is-not-a-party", "apple-pay:rule.cardholder-authenticates-before-every-payment", "apple-pay:rule.merchant-never-sees-the-card-number", "apple-pay:rule.eci-indicator-must-be-passed-on", "apple-pay:rule.merchant-key-and-payload-security", "apple-pay:rule.card-and-merchant-terms-keep-governing" ], "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.", "relations": [ { "type": "see_also", "to": "visa:liability", "note": "The Visa rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:liability", "note": "The Mastercard rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa-dispute:10.1", "note": "Visa counterfeit fraud.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa-dispute:10.2", "note": "Visa EMV liability shift, non-counterfeit fraud.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa-dispute:10.4", "note": "Visa other fraud, card-absent environment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "google-pay:liability", "note": "The same facet for the other pass-through wallet.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "apple-pay:src.developer-program-license-agreement", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "google-pay:liability", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "apple-pay:rule.prohibited-website-uses", "apple-pay:rule.no-staged-wallet-behind-apple-pay", "apple-pay:rule.what-the-apis-may-be-used-for", "apple-pay:rule.display-parity-and-primary-option", "apple-pay:rule.apple-cash-and-balance-transfers", "apple-pay:rule.apple-may-disable-on-a-site" ], "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.", "relations": [ { "type": "see_also", "to": "visa:limits", "note": "The Visa rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:limits", "note": "The Mastercard rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "google-pay:limits", "note": "The same facet for the other pass-through wallet.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "apple-pay:src.acceptable-use-guidelines-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "google-pay:limits", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "apple-pay:rule.payment-token-structure", "apple-pay:rule.decrypted-payment-data-fields", "apple-pay:rule.detailed-payment-data-3dsecure-and-emv", "apple-pay:rule.eci-indicator-must-be-passed-on", "apple-pay:rule.merchant-token-for-recurring-charges", "apple-pay:rule.signature-and-decryption-checks" ], "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.", "relations": [ { "type": "see_also", "to": "visa:messages", "note": "The Visa rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:messages", "note": "The Mastercard rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "google-pay:messages", "note": "The same facet for the other pass-through wallet.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "apple-pay:src.payment-token-format-reference", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "google-pay:messages", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "apple-pay:rule.apple-is-not-a-party", "apple-pay:rule.who-provides-apple-pay-and-is-not-a-bank", "apple-pay:rule.issuer-and-network-decide-provisioning", "apple-pay:rule.merchant-use-of-the-payload", "apple-pay:rule.intermediary-party-duties", "apple-pay:rule.web-view-host-may-not-touch-the-payload", "apple-pay:rule.merchant-processes-through-its-own-chain" ], "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.", "relations": [ { "type": "see_also", "to": "visa:participants", "note": "The Visa rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:participants", "note": "The Mastercard rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "google-pay:participants", "note": "The same facet for the other pass-through wallet.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "google-pay:participants", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "apple-pay:rule.no-wallet-recall", "apple-pay:rule.apple-is-not-a-party", "apple-pay:rule.merchant-verifies-then-processes" ], "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].", "relations": [ { "type": "see_also", "to": "visa:recall", "note": "The Visa rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:recall", "note": "The Mastercard rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "google-pay:recall", "note": "The same facet for the other pass-through wallet.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "apple-pay:src.support-118270-refunds", "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." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "google-pay:recall", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "apple-pay:rule.merchant-refunds-to-the-card", "apple-pay:rule.device-account-number-differs-from-the-card", "apple-pay:rule.merchant-never-sees-the-card-number" ], "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.", "relations": [ { "type": "see_also", "to": "visa:refund", "note": "The Visa rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:refund", "note": "The Mastercard rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "google-pay:refund", "note": "The same facet for the other pass-through wallet.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "apple-pay:src.support-118270-refunds", "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." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "google-pay:refund", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "apple-pay:rule.no-wallet-dispute-channel", "apple-pay:rule.card-and-merchant-terms-keep-governing", "apple-pay:rule.apple-is-not-a-party", "apple-pay:rule.device-account-number-differs-from-the-card" ], "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].", "relations": [ { "type": "see_also", "to": "visa:return", "note": "The Visa rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:return", "note": "The Mastercard rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa-dispute:10.1", "note": "Visa counterfeit fraud, a condition where a token matters.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa-dispute:10.2", "note": "Visa EMV liability shift for a non-counterfeit fraud transaction, the in-store side.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa-dispute:10.4", "note": "Visa other fraud, card-absent environment, the in-app and web side.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa-dispute:13.1", "note": "Merchandise or services not received, a dispute about the sale rather than the wallet.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "google-pay:return", "note": "The same facet for the other pass-through wallet.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "apple-pay:src.apple-pay-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." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "google-pay:return", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "apple-pay:rule.apple-reencrypts-the-credential", "apple-pay:rule.merchant-processes-through-its-own-chain", "apple-pay:rule.apple-is-not-a-party", "apple-pay:rule.merchant-never-sees-the-card-number" ], "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.", "relations": [ { "type": "see_also", "to": "visa:settlement", "note": "The Visa rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:settlement", "note": "The Mastercard rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "google-pay:settlement", "note": "The same facet for the other pass-through wallet.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "apple-pay:src.apple-pay-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." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "google-pay:settlement", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rail.au-npp", "id": "rail.au-npp", "class": "Rail", "rail": "au-npp", "name": "New Payments Platform (Australia)", "governing_authority": "NPP Australia Limited", "country": "AU", "currency": "AUD", "operators": [ "NPP Australia Limited (scheme operator, a subsidiary of Australian Payments Plus Limited)", "Reserve Bank of Australia (Fast Settlement Service, a component of RITS)", "SWIFT (NPP Basic Infrastructure and the Mandate Management Service, under contract to NPPA)" ], "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" ], "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Parts 4, 6, 7, 8, 14, 17 and 18, and the definitions in Regulation 1.1", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.npp-product-rules-v31", "section": "the whole document, opened 2026-09-21 and found to carry no text", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp-reject:rail.au-npp-reject", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "source_class": null, "effective_status_reason": null, "used_by": [ { "from": "au-npp-reject:rail.au-npp-reject", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:exc.clearing-rejection", "id": "exc.clearing-rejection", "rail": "au-npp", "class": "Exception", "name": "Clearing rejection", "summary": "The receiving institution answers the clearing request with a rejection carrying a reason code. Nothing settles, nothing is credited and nothing has to be sent back. The paying institution tells its customer the payment failed, in whatever words it chooses.", "money_moves": false, "outcome": "The payment does not happen. No value moves at any point and there is no return, no claim and no window to watch.", "relations": [ { "type": "initiated_by", "to": "au-npp:role.payee-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "au-npp:role.payee-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "enters", "to": "au-npp:state.rejected-at-clearing", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 6.3(a)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 6.3(a) confirms a Payee Participant rejects a Clearing Request by initiating a Clearing Notification with a valid and applicable Reason Code within the configured timeout." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.decision-points-the-payee-participant-accepts-or-rejects", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.limits-a-zero-value-payment-is-forbidden", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.messages-a-rejected-clearing-request-carries-a-reason-code", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:exc.duplicate-or-error-payment-return-request", "id": "exc.duplicate-or-error-payment-return-request", "rail": "au-npp", "class": "Exception", "name": "Request for the return of a duplicate or error payment", "summary": "The paying institution finds it has sent the same payment twice, or has sent a payment its own mistake caused, or has sent one for a payer who is not a user as the ePayments Code uses that word. It may ask for the money back and that is all it may do.", "money_moves": true, "outcome": "The receiving institution must acknowledge and must assess, and then may return the payment if it is satisfied. The rulebook says in terms that the return is at its discretion. Whatever it decides, the paying institution bears full liability to make its own customer whole for a settled duplicate or for a payment its own error caused.", "relations": [ { "type": "initiated_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "au-npp:role.payee-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "enters", "to": "au-npp:state.returned", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 6.4(c) and 6.5(c), and the definitions of Duplicate Payment and Error Payment", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulations 6.4(c) and 6.5(c) and the definitions of Duplicate Payment and Error Payment confirm the Payer Participant may request return of a settled Duplicate or Error Payment, with the Payee Participant's return expressly at its own discretion." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.recall-a-duplicate-or-error-payment-return-is-discretionary", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.recall-the-payer-participant-carries-its-own-customers-loss", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:exc.mandate-claim", "id": "exc.mandate-claim", "rail": "au-npp", "class": "Exception", "name": "Mandate claim", "summary": "The payer's institution claims, for its customer, that an initiating party sent a mandate payment initiation request and got a payment the mandate or the customer did not authorise. Not authorised is defined widely: it covers a mandate whose authorisation the payer's institution never recorded, a mandate that was suspended or cancelled when the request went, and fraud whatever the record in the operator's database says.", "money_moves": true, "outcome": "Where the claim is substantiated the initiating side pays the payer's institution under the indemnity, reduced by anything already recovered from the receiving institution. Who has to prove what turns on the kind of mandate, which is the sharpest difference between the two PayTo mandates. If the two institutions disagree about the evidence, the rulebook's own dispute resolution process is open to them. The time in which the indemnity must be paid is in the procedures and is not public.", "relations": [ { "type": "initiated_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "au-npp:role.initiating-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "enters", "to": "au-npp:state.returned", "note": "[Inference] the indemnity payment is not itself an NPP Payment Return, so the state is entered only where the initiating side returns the funds through the unsolicited mandate payment return process the procedures describe.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 17.10(a) to (h), and 17.9(b)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulations 17.10(a) to (h) confirm a Mandate Claim is a claim by the Payer Participant that an initiated Mandate Payment was not authorised by the Mandate or the Payer Customer, indemnified by the Initiating Participant, with the burden of proof split by Mandate type; Regulation 17.9(b) confirms the Unsolicited Mandate Payment Return process for a duplicate or erroneous Mandate Payment Initiation Request." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:mandate.authorised-payment-mandate", "type": "disputed_via", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:mandate.migrated-ddr-mandate", "type": "disputed_via", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.liability-a-sponsor-takes-full-risk-on-the-users-it-sponsors", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.liability-the-initiating-participant-indemnifies-against-mandate-claims", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-a-migrated-mandate-claim-is-deemed-substantiated", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-a-request-may-not-be-sent-unless-the-mandate-is-active", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-an-authorised-mandate-claim-is-deemed-substantiated-by-the-record", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-indemnity-settlement-timeframes-are-not-public", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-the-record-is-evidence-of-quantum-frequency-and-beneficiary", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:exc.misdirected-payment-return-request", "id": "exc.misdirected-payment-return-request", "rail": "au-npp", "class": "Exception", "name": "Request for the return of a misdirected payment", "summary": "A payment addressed by PayID landed in the wrong account because the institution that registered or maintained that PayID got it wrong. This is a different defined term from a mistaken payment and the difference is whose error it was: here it was an institution's, not the payer's.", "money_moves": true, "outcome": "The paying institution may ask for it back. The receiving institution must acknowledge and must assess, and must send the money back if it is satisfied the payment was misdirected. The indemnity that follows a badly registered alias sits with the registering institution rather than with the payer's.", "relations": [ { "type": "initiated_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "au-npp:role.payee-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "enters", "to": "au-npp:state.returned", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 6.5(b) and its note, and the definition of Misdirected Payment", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 6.5(b) and its note and the definition of Misdirected Payment confirm a Misdirected Payment is one sent to the wrong account because the Registering Participant did not correctly register or maintain the Alias, with the Payee Participant required to return it if satisfied, and the Registering Participant's indemnity under Regulation 8.4(i)." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.liability-a-registering-participant-indemnifies-a-misdirected-payment", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.recall-a-misdirected-payment-is-returned-if-the-payee-participant-is-satisfied", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:exc.mistaken-internet-payment", "id": "exc.mistaken-internet-payment", "rail": "au-npp", "class": "Exception", "name": "ePayments Code mistaken internet payment", "summary": "A customer tells their own institution they sent money to the wrong account because they entered or chose the wrong details or were given the wrong details. This is the consumer facing process that sits above the scheme's own return machinery, it belongs to the ePayments Code rather than to the rulebook, and it binds only institutions that subscribe to that Code. It is explicitly not about scams.", "money_moves": true, "outcome": "The sending institution investigates and, if satisfied, asks the receiving institution for the money back within 5 business days of the report. What happens next turns on when the customer reported it: inside 10 business days the money comes back, between 10 business days and 7 months the recipient gets a chance to show entitlement first, and after 7 months it comes back only if the recipient agrees. Where the money is not all there the receiving institution weighs both customers' interests and decides how much to pursue. The customer is told the outcome in writing within 30 business days and may take the matter to the external dispute resolution scheme.", "relations": [ { "type": "initiated_by", "to": "au-npp:role.payer-customer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "au-npp:role.receiving-adi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.epayments-code-2022", "section": "clauses 25.2, 28 to 36", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "ASIC's ePayments Code of 2 June 2022, at the clauses named in the record's links, read 2026-09-21.", "confidence": "high" }, "currency": { "effective_since": "2022-06-02", "effective_to": null, "effective_note": "Drafted 2026-09-21 from ASIC's own current text of the ePayments Code. The Code is voluntary and binds subscribers only; which institutions subscribe was not established here.", "source_edition": "ePayments Code as published by ASIC on 2 June 2022, read 2026-09-21.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.epayments-code-2022", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Clauses 25.2 and 28 to 36 confirm the mistaken internet payment process: the definition, the reporting and acknowledgement duties, the three time-based tiers, the insufficient funds discretion, the written outcome duty, and the complaint and AFCA pathway." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.consumer-law-afca-hears-a-mistaken-payment-complaint", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.refund-reported-after-7-months-only-with-consent", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.refund-reported-between-10-business-days-and-7-months", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.refund-reported-within-10-business-days-the-money-comes-back", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.refund-the-outcome-in-writing-within-30-business-days", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.refund-the-receiving-adi-answers-within-5-business-days", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.refund-the-sending-adi-must-investigate-and-ask-within-5-business-days", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.refund-where-the-funds-are-short-the-receiving-adi-weighs-the-two-customers", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:exc.mistaken-payment-return-request", "id": "exc.mistaken-payment-return-request", "rail": "au-npp", "class": "Exception", "name": "Request for the return of a mistaken payment", "summary": "The paying institution works out that a settled payment went to the wrong account because its own customer, who is a user as the ePayments Code uses that word, put in or chose the wrong details. It must ask for the payment back. This is the strongest of the four wrong payment routes and the only one where the receiving institution is obliged to act rather than permitted to.", "money_moves": true, "outcome": "The receiving institution must acknowledge the request, must use reasonable endeavours to assess whether it really is a mistaken payment, must say whether and when it will send the money back, and must effect any return that is needed. If it does assess properly, the paying institution indemnifies it for what the return costs it; if it does not, the loss is its own. Every timeframe in this route lives in the procedures and is not public.", "relations": [ { "type": "initiated_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "au-npp:role.payee-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "enters", "to": "au-npp:state.returned", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 6.5(a) and the definition of Mistaken Payment", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 6.5(a) and the definition of Mistaken Payment confirm a Mistaken Payment is one a user as the ePayments Code defines that term sent to the wrong account by their own error, with the Payee Participant required to acknowledge, use reasonable endeavours to assess, and effect any necessary return." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.recall-a-mistaken-payment-must-be-assessed-and-returned-if-needed", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.recall-the-payer-participant-indemnifies-a-good-faith-return", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.return-windows-and-deadlines-are-not-public", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:exc.payment-initiation-rejection", "id": "exc.payment-initiation-rejection", "rail": "au-npp", "class": "Exception", "name": "Payment initiation rejection", "summary": "A corporate, government or third party customer sends its own institution an instruction to make one or more payments, and the institution answers with a status report saying it will not. This is the leg the only published Australian code list describes, and it sits before the scheme's own machinery: nothing has reached the platform, no other institution has seen anything, and no money has moved. The leg itself is not one the scheme requires an institution to offer at all.", "money_moves": false, "outcome": "The instruction does not become a payment. The status report carries a rejection status and a reason code, and the authority notes that an institution may offer alternative values for both. Because nothing settled there is nothing to return and no claim to make; the customer corrects the instruction, or asks its own institution what its requirements actually are, and sends it again. A rejection at group level can also come back as a partial processing status where a bulk file is being handled in portions.", "relations": [ { "type": "initiated_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.npp-payment-initiation-messages-v4", "section": "Background, Appendix E and Appendix F, and the notes under each appendix", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Payment Initiation Messages, technical guidance v4.0 of 20 November 2025, published by Australian Payments Plus and NPP Australia, read 2026-09-21.", "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. Drafted 2026-09-21. This exception describes a leg the guidance itself says is proprietary and at each institution's discretion, so what an institution actually does on it may differ.", "source_edition": "NPP Payment Initiation Messages v4.0, dated 20 November 2025, uploaded March 2026, read 2026-09-21.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-payment-initiation-messages-v4", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "The Background section and Appendices E and F, with their notes, confirm a payment instruction on the customer to institution leg may be rejected with a status code and a reason code from the authority's own indicative list, on a leg the FI's acceptance of is proprietary and at its discretion." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC02", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC03", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC05", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC06", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC07", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC13", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC14", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC15", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AG01", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AG03", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AGNT", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM01", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM02", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM03", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM04", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM06", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM09", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM12", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM19", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM21", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:BE06", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:BE08", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:BE22", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:CH20", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:CH21", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:CURR", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:DT02", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:DT04", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:FF10", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:MD01", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:NARR", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:NAUT", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:TD03", "type": "raised_in", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:exc.settlement-rejection", "id": "exc.settlement-rejection", "rail": "au-npp", "class": "Exception", "name": "Settlement rejection, which voids a cleared payment", "summary": "The settlement service finds the paying institution does not have the funds, rejects the settlement request, and the payment that the receiving institution had already accepted is deemed immediately void. This is the exception on this rail that people miss, because it happens after a payment has been accepted and it produces nothing that looks like a reject or a return.", "money_moves": false, "outcome": "The cleared payment stops existing. The paying institution owes nothing to the receiving institution or to the payee, and decides for itself whether to send the message again or to send it marked as a retry. What happens to a credit the receiving institution had already given is not answered by any public rule.", "relations": [ { "type": "initiated_by", "to": "au-npp:role.rba-fss-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "enters", "to": "au-npp:state.voided-by-settlement-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 6.2(e), 6.2(f)(ii), 7.4(b)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulations 6.2(e) and 6.2(f)(ii) confirm a Cleared payment the FSS rejects is deemed immediately void with no liability on the Payer Participant, who alone decides whether to Replay or Retry, and Regulation 7.4(b) confirms rejection of a Settlement Request automatically voids the associated Cleared payment." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.finality-a-cleared-payment-the-fss-rejects-is-void", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.finality-no-cancel-or-recall-once-the-message-is-in-the-gateway", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.finality-the-payer-participant-alone-decides-to-replay-or-retry", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.settlement-the-fss-tests-funds-and-settles-or-rejects", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:exc.spf-scam-complaint", "id": "exc.spf-scam-complaint", "rail": "au-npp", "class": "Exception", "name": "Scams Prevention Framework complaint", "summary": "A customer complains to a regulated entity about an activity that is or may be a scam, or about how the entity behaved around one. This is the route Australia built instead of a reimbursement duty, and it is a duty and remedy framework rather than a right to be paid back.", "money_moves": true, "outcome": "The entity must run the complaint through an accessible internal dispute resolution mechanism, must give a statement about whether it met its own obligations, and must have regard to any process and to any liability apportionment guidelines the framework rules prescribe. From 1 September 2026 a bank must belong to an authorised external dispute resolution scheme. A victim who wants money recovers it by proving in court that a contravention caused the loss, within 6 years, against liability apportioned among concurrent wrongdoers who may include a telecommunications provider or a digital platform. There is no cap, no percentage split between sending and receiving institution and no duty to pay without fault.", "relations": [ { "type": "initiated_by", "to": "au-npp:role.payer-customer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "au-npp:role.spf-regulated-entity", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.scams-prevention-framework-act-2025", "section": "sections 58BZB to 58BZG, 58FD and 58FZC to 58FZF", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.spf-regulated-sectors-designation-2026", "section": "sections 11, 12 and provision 101", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Scams Prevention Framework Act 2025 (No. 15, 2025) as made and the Competition and Consumer (Scams Prevention Framework, Regulated Sectors) Designation 2026, at the sections named in the record's links, both read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-01", "effective_to": null, "effective_note": "The framework reaches banking in stages. The Designation's transitional provision 101 turned most of Part IVF off for covered banking services until before 1 September 2026, left the external dispute resolution membership section on from that date, and ends before 31 March 2027, when the rest applies. Read as made rather than as a current compilation [Unverified].", "source_edition": "Scams Prevention Framework Act 2025 (No. 15, 2025) as made, read 2026-09-21, together with the Competition and Consumer (Scams Prevention Framework, Regulated Sectors) Designation 2026 (F2026L00627), read the same day. Part IVF of the Competition and Consumer Act 2010 was not read as a current compilation, so a later amendment to a cited section is not held [Unverified].", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.scams-prevention-framework-act-2025", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Sections 58BZB to 58BZG confirm the reporting, internal dispute resolution and EDR scheme membership duties a regulated entity owes, and sections 58FD and 58FZC to 58FZF confirm the victim's fault-based action for damages and its proportionate liability treatment among concurrent wrongdoers." }, { "source": "au-npp:src.spf-regulated-sectors-designation-2026", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Sections 11 and 12 confirm covered banking services and ASIC as their SPF sector regulator, and provision 101 confirms the transitional dates on which these duties reach banking." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.consumer-law-external-dispute-resolution-membership-from-2026-09-01", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.consumer-law-internal-dispute-resolution-and-apportionment-guidelines", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.liability-a-scam-victim-recovers-by-proving-a-contravention", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:exc.unauthorised-transaction-claim", "id": "exc.unauthorised-transaction-claim", "rail": "au-npp", "class": "Exception", "name": "ePayments Code unauthorised transaction claim", "summary": "A customer says a transaction on their account was not theirs. The Code then allocates the loss between the customer and their institution. Its first rule is the one people most often get wrong: a transaction the customer performed themselves, or that anybody performed with their knowledge and consent, is not an unauthorised transaction at all, so a payment made because the customer was deceived is outside this route entirely.", "money_moves": true, "outcome": "Where the Code says the holder is not liable, the institution carries the loss, including for any payment that could be made using an identifier alone with no passcode or device. Where the institution can prove on the balance of probability that the customer contributed through fraud, a passcode breach or an unreasonable delay in reporting, the customer carries the actual losses inside their own daily and periodic limits and account balance. Where none of that applies and a passcode was needed, the customer carries the least of 150 dollars, the balance available, and the actual loss at the time of reporting.", "relations": [ { "type": "initiated_by", "to": "au-npp:role.payer-customer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "au-npp:role.subscriber", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.epayments-code-2022", "section": "clauses 9.2, 9.3, 10.1 to 10.3, 11.2, 11.5 and 11.7", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "ASIC's ePayments Code of 2 June 2022, at the clauses named in the record's links, read 2026-09-21.", "confidence": "high" }, "currency": { "effective_since": "2022-06-02", "effective_to": null, "effective_note": "Drafted 2026-09-21 from ASIC's own current text of the ePayments Code. The Code is voluntary and binds subscribers only; which institutions subscribe was not established here.", "source_edition": "ePayments Code as published by ASIC on 2 June 2022, read 2026-09-21.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.epayments-code-2022", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Clauses 9.2, 9.3, 10.1 to 10.3, 11.2, 11.5 and 11.7 confirm an unauthorised transaction excludes one the user performed or consented to, and set out the holder's liability positions: not liable in the clause 10.1 to 10.3 circumstances, liable for actual losses where the subscriber proves contribution under 11.2 or 11.5 subject to transaction limit caps, and liable for at most 150 dollars under the residual rule in 11.7." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.liability-a-deceived-payer-is-not-an-unauthorised-transaction", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.liability-the-holder-is-liable-where-the-subscriber-proves-contribution", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.liability-the-holder-is-not-liable-where-an-identifier-alone-can-pay", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.liability-the-residual-cap-is-150-dollars", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:exc.unsolicited-return", "id": "exc.unsolicited-return", "rail": "au-npp", "class": "Exception", "name": "Unsolicited return", "summary": "The receiving institution decides on its own to send a settled payment back, without anybody asking. The rulebook allows only one way of doing it, the return message, and leaves whether to tell the account holder, or to ask them first, to the institution.", "money_moves": true, "outcome": "A new payment travels in the opposite direction and settles in its own right. The original payment stays settled and final. A zero value return may not be sent.", "relations": [ { "type": "initiated_by", "to": "au-npp:role.payee-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "au-npp:role.payee-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "enters", "to": "au-npp:state.returned", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 6.6 and its note, and Regulation 6.1(c)(ii)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 6.6 and its note confirm a Payee Participant may return a Cleared payment on its own initiative by initiating an NPP Payment Return complying with the Procedures, leaving notification of the account holder to its own proprietary arrangements, and Regulation 6.1(c)(ii) confirms the return may not carry a zero value." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.return-a-return-is-a-new-payment-going-the-other-way", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.return-an-unsolicited-return-is-the-payee-participants-own-choice", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.return-only-a-cleared-payment-may-be-returned", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:mandate.authorised-payment-mandate", "id": "mandate.authorised-payment-mandate", "rail": "au-npp", "class": "Mandate", "name": "Authorised Payment Mandate (a PayTo agreement)", "summary": "The ordinary PayTo mandate. It is a record of a payment authorisation the payer gives in favour of a business or a payment initiator, and the record does not live with either of them: it lives in the Mandate Management Service, a central access controlled database the scheme operator runs, under a unique identifier the database itself generates. It gives the holder the right to send requests instructing the payer's own institution to make payments inside the mandate's terms, and it is only active once the payer's institution has recorded in the database that the payer authorised it. Three parties act and an operator holds the record, which is the thing that makes it unlike every other mandate in the corpus.", "form": "A record in the Mandate Management Service, the scheme operator's own central database, identified by a mandate identifier the database generates. It is not a document either party keeps. The payer authorises it in their own institution's channel after that institution delivers the authorisation request to them in near real time, and the institution then records the confirmation in the database. Lookup rights belong to the parties to the mandate and the information in the record is confidential to them.", "scope": [ "a stated amount, purpose and frequency the payer authorised, which the record itself is the evidence of. No amount is typed as a constraint because no source gives a figure: what the sources give is the shape of the range, and three of the reason codes the authority publishes sit at its edges, one for an amount below the minimum the agreement allows, one for an amount that is not the amount agreed or expected, and one for an amount above a limit the payer and their own bank agreed", "one off, ad hoc or recurring payments to the business or provider named in it", "payments the payer's own institution makes as ordinary credit pushes; nothing is pulled", "active only while the payer's institution has recorded the payer's authorisation in the operator's database" ], "constraints": { "recurrence": { "max_occurrences": null, "text": "The mandate states the frequency the payer authorised, and the record in the operator's database is the evidence of it. The rulebook sets no ceiling of its own on the number of payments and no public document gives one." }, "counterparties": { "text": "The mandate names the business or payment initiator it is given to, and where a beneficiary is recorded the record is the evidence of that too. A payment initiator's mandate may be moved to a different participant or connected institution on the initiator's instruction without the authorisation changing." } }, "relations": [ { "type": "given_by", "to": "au-npp:role.payer-customer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "given_to", "to": "au-npp:role.mps-user", "note": "The authorisation runs to the business or payment initiator, but the record is held by the scheme operator and the authorisation is validated and recorded by the payer's own institution. One target uid cannot carry all three positions; the operator's custody is in form and in the rules this mandate is governed by.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "authorises", "to": "au-npp:txn.mandate-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.mandate-a-mandate-is-a-record-in-the-scheme-operators-database", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.mandate-participation-is-mandatory-for-a-payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.mandate-authorisation-is-delivered-in-near-real-time", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.mandate-a-request-may-not-be-sent-unless-the-mandate-is-active", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.mandate-an-amount-or-frequency-change-comes-from-the-business", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.mandate-a-mandate-may-be-ported-to-another-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.mandate-data-is-confidential-to-the-parties", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.mandate-an-authorised-mandate-claim-is-deemed-substantiated-by-the-record", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "revoked_via", "to": "au-npp:rule.mandate-the-payer-customer-can-view-suspend-cancel-and-amend", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "evidenced_by", "to": "au-npp:rule.mandate-the-record-is-evidence-of-quantum-frequency-and-beneficiary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "disputed_via", "to": "au-npp:exc.mandate-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:mandate.migrated-ddr-mandate", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:mandate.consumer-debit-authorization", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:mandate.standing-order-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 17.1(b) and (c), 17.2(e), 17.6(c), 17.7(a), 17.8(b), 17.10(d) and (f), and the definition of Active", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.auspayplus-payto-faqs", "section": "what a PayTo agreement is, how PayTo works, and managing agreements", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024 at the regulations named in the links, and Australian Payments Plus's PayTo FAQs for the customer facing description. Both read 2026-09-21. The typed constraints state only what the sources support: the sources say the mandate carries an amount, purpose and frequency and that the record is the evidence of them, and they give no figure, so no amount range is typed at all and the shape of the range is described in scope instead. That description rests on the reason code meanings in the NPP Payment Initiation Messages guidance v4.0, read the same day.", "confidence": "medium" }, "currency": { "effective_since": "2020-12-02", "effective_to": null, "effective_note": "Effective since 2020-12-02: the definition of Active carries that drafting date, and the porting provisions took effect 5 May 2023 Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulations 17.1(b) and (c), 17.2(e), 17.6(c), 17.7(a), 17.8(b) and 17.10(d) and (f) and the definition of Active confirm an Authorised Payment Mandate is a record of the Payer Customer's authorisation, held confidentially in the MMS, activated only once the Payer Participant records the customer's authorisation confirmation, and evidenced for a Mandate Claim by the record's own terms of amount, frequency and beneficiary." }, { "source": "au-npp:src.auspayplus-payto-faqs", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "The FAQ pages confirm what a PayTo agreement is and how a payer manages it in their own online banking, in the same terms as the Regulations' Authorised Payment Mandate provisions." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:mandate.migrated-ddr-mandate", "type": "derived_from", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:mandate.migrated-ddr-mandate", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AG01", "type": "concerns", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM06", "type": "concerns", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM09", "type": "concerns", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM21", "type": "concerns", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:MD01", "type": "concerns", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:NAUT", "type": "concerns", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:mandate.debtor-payment-arrangement", "id": "mandate.debtor-payment-arrangement", "rail": "au-npp", "class": "Mandate", "name": "Debtor Payment Arrangement", "summary": "The third thing the Mandate Management Service can hold, and the thinnest. A payer's own institution may choose to store records of these arrangements in the database, and it is answerable for payments made in connection with them. What one is, who gives it and to whom, and how it is authorised, amended or ended are all defined in the procedures rather than in the published rulebook, so Orca can say that the record type exists and almost nothing else.", "form": "Not held. The published rulebook defines this term only by pointing at the NPP Procedures Volume 6, which is available to members and direct affiliates only and was not consulted. What is known is that storing these in the operator's database is optional for the payer's institution and that the institution is responsible for payments made in connection with them.", "scope": [ "not held: the arrangement's scope is defined in a document Orca cannot read" ], "relations": [ { "type": "given_by", "to": "au-npp:role.payer-customer", "note": "[Inference] from the term itself and from the payer participant being the party that stores the record. No read source says who gives one.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "given_to", "to": "au-npp:role.payer-participant", "note": "[Inference] the payer's own institution is the party that opts to store the record and is responsible for the payments. No read source names a holder.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "authorises", "to": "au-npp:txn.mandate-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.mandate-a-mandate-is-a-record-in-the-scheme-operators-database", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 17.1(b) final paragraph, Regulation 17.8(f), and the definition of Debtor Payment Arrangement, which points at the NPP Procedures", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, Regulations 17.1(b) and 17.8(f) and the definition of Debtor Payment Arrangement, read 2026-09-21. The definition gives the meaning to the NPP Procedures, which are available to members and direct affiliates only and were not consulted, so everything about this arrangement beyond its existence and the storing institution's responsibility is not held.", "confidence": "low" }, "currency": { "effective_since": "2020-12-02", "effective_to": null, "effective_note": "Effective since 2020-12-02: the definition carries that drafting date Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified]. The substance of this record sits in the NPP Procedures Volume 6, which is participant material and was not consulted.", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "primary_not_public": true, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:mandate.migrated-ddr-mandate", "id": "mandate.migrated-ddr-mandate", "rail": "au-npp", "class": "Mandate", "name": "Migrated DDR Mandate", "summary": "A PayTo mandate created out of an existing direct debit arrangement, and the one mandate in the corpus that nobody consented to. The business and its sponsoring participant create it in the operator's database unilaterally, and it is deemed active the moment it is created, with no authorisation step and no message to the payer's institution asking for one. Its safeguards are notice and delay rather than consent, and its risk shows up in the claim rules, where the burden of proof falls on the sponsor rather than on the payer.", "form": "A record the business's sponsoring participant creates in the Mandate Management Service from an existing direct debit request, mapped across as the procedures prescribe, and deemed active on creation. The payer never authorises it. The payer's own institution may choose to satisfy itself that the record matches its customer's existing direct debit and may ask the customer to confirm, but it is not obliged to, and pending any word from the customer it must keep processing requests against the record.", "scope": [ "an existing direct debit arrangement and nothing else; one of these cannot be created from scratch", "deemed active on creation, with no payer authorisation step", "unusable for a payment initiation request until 5 days after it was created", "conditional on the business having given the payer written notice, as its direct debit service agreement requires or at least 14 days beforehand", "conditional on direct debit processing of the same arrangement stopping from the migration date, except in a genuine outage" ], "constraints": { "execution_window": { "from": "2023-05-05", "to": null, "text": "No public document gives a date on which this kind of mandate stops being creatable. The date recorded here is not an execution window of the mandate but the earliest date the whole of the part that governs it was in force; the industry target for retiring the direct debit system these mandates come from is 2030, which would end them, and that target rests on a source not read here [Unverified]." }, "recurrence": { "max_occurrences": null, "text": "The terms are the terms of the direct debit arrangement the record was mapped from, not terms the payer gave the operator's database. That is why a claim about one is tested against the original direct debit authorisation." }, "counterparties": { "text": "The business is the direct debit user the participant already sponsored, deemed approved as a user of the service by the act of creating the record, and its BECS user identifier must be carried in the record so the payer's institution can check the arrangement against its own customer's history." } }, "relations": [ { "type": "given_by", "to": "au-npp:role.payer-customer", "note": "Only in the sense that the payer once authorised the direct debit this record was mapped from. No authorisation was given for this record, and the rulebook does not pretend otherwise.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "given_to", "to": "au-npp:role.mps-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "authorises", "to": "au-npp:txn.mandate-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "derived_from", "to": "au-npp:mandate.authorised-payment-mandate", "note": "Not derived in the sense of being granted under it. The two are the two kinds of mandate the service holds, and this link records that they are the same class of record in the same database, differing on whether the payer consented. The rulebook reaches the opposite way: the rules on authorisation delivery and porting facilitation are switched off for this one.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.mandate-a-migrated-mandate-is-created-without-a-consent-step", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.mandate-fourteen-days-notice-before-a-migrated-mandate-is-created", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.mandate-five-days-before-a-migrated-mandate-may-be-used", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.mandate-the-payer-participant-keeps-processing-pending-word", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.mandate-a-migrated-mandate-claim-is-deemed-substantiated", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.mandate-a-request-may-not-be-sent-unless-the-mandate-is-active", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.mandate-data-is-confidential-to-the-parties", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "revoked_via", "to": "au-npp:rule.mandate-the-payer-customer-can-view-suspend-cancel-and-amend", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "evidenced_by", "to": "au-npp:rule.mandate-the-record-is-evidence-of-quantum-frequency-and-beneficiary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "disputed_via", "to": "au-npp:exc.mandate-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:mandate.authorised-payment-mandate", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 17.4(a) to (f), 17.6(c)(viii) and 17.10(c)(ii) and (e)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.auspayplus-payto-faqs", "section": "moving direct debits to PayTo agreements", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024 at Regulation 17.4 and Regulation 17.10(e), and Australian Payments Plus's PayTo FAQs, which put the same arrangement to customers as 14 days notice, an opt out during that period, no re-approval and 5 days before the first debit. Both read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "2021-06-30", "effective_to": null, "effective_note": "Effective since 2021-06-30: Regulation 17.4(d) carries that drafting date, and Regulation 17.4(e) was amended 7 December 2021 Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulations 17.4(a) to (f) confirm a Migrated DDR Mandate is created unilaterally from an existing BECS direct debit arrangement and deemed Active on creation, with the notice, evidence and cessation safeguards in 17.4(c); Regulation 17.6(c)(viii) confirms the authorisation-delivery and porting duties do not apply to it; Regulation 17.10(c)(ii) and (e) confirm its Mandate Claims are deemed substantiated absent written evidence from the sponsor." }, { "source": "au-npp:src.auspayplus-payto-faqs", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "The FAQ pages confirm the 14 day notice, no re-approval needed, opt-out during the notice period, and 5 day delay before the first debit that a direct debit customer experiences when their business moves them to PayTo." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:mandate.authorised-payment-mandate", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:role.afca", "id": "role.afca", "rail": "au-npp", "class": "Role", "name": "Australian Financial Complaints Authority (AFCA)", "summary": "The external dispute resolution scheme a customer reaches when their own institution does not resolve a complaint. The ePayments Code says a user who is not satisfied with how a mistaken internet payment report was handled must be able to complain to it about the sending institution, and that both institutions must cooperate with it and comply with its decisions. The Scams Prevention Framework adds a statutory membership duty for banks from 1 September 2026.", "kind": "authority", "relations": [ { "type": "sourced_from", "to": "au-npp:src.epayments-code-2022", "section": "clauses 36.3, 36.4 and 36.5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.spf-regulated-sectors-designation-2026", "section": "provision 101(3) and (4)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links; ASIC's ePayments Code of 2 June 2022; the Scams Prevention Framework Act 2025 and the Regulated Sectors Designation 2026; the Reserve Bank's About RITS page; and Australian Payments Plus's PayTo FAQs and payment initiation guidance v4.0. All read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.epayments-code-2022", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Clauses 36.3 to 36.5 confirm a user unsatisfied with a sending ADI's complaint handling must be able to take the complaint to AFCA, and that both the sending and receiving ADI must cooperate with AFCA and comply with its decisions." }, { "source": "au-npp:src.spf-regulated-sectors-designation-2026", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Section 101(3) and (4) confirms the Designation switches on section 58BZG, the SPF EDR scheme membership provision, for covered banking services from 1 September 2026." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.consumer-law-afca-hears-a-mistaken-payment-complaint", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.consumer-law-external-dispute-resolution-membership-from-2026-09-01", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.refund-the-outcome-in-writing-within-30-business-days", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:role.asic", "id": "role.asic", "rail": "au-npp", "class": "Role", "name": "Australian Securities and Investments Commission (ASIC)", "summary": "The regulator that writes and administers the ePayments Code, which is voluntary and binds only the institutions that subscribe to it, and which is the source of the strongest current consumer protections on this rail. Since the banking designation of May 2026 ASIC is also the sector regulator for banking under the Scams Prevention Framework.", "kind": "authority", "relations": [ { "type": "sourced_from", "to": "au-npp:src.epayments-code-2022", "section": "the Code as a whole, and clause 45.1 on ASIC's monitoring", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.spf-regulated-sectors-designation-2026", "section": "section 12", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links; ASIC's ePayments Code of 2 June 2022; the Scams Prevention Framework Act 2025 and the Regulated Sectors Designation 2026; the Reserve Bank's About RITS page; and Australian Payments Plus's PayTo FAQs and payment initiation guidance v4.0. All read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.epayments-code-2022", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "The Code names ASIC as its administering regulator throughout, and clause 45.1 confirms ASIC's monitoring power over subscriber compliance." }, { "source": "au-npp:src.spf-regulated-sectors-designation-2026", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Section 12 confirms ASIC is designated as the SPF sector regulator for the banking regulated sector described in section 11." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.consumer-law-the-epayments-code-is-voluntary", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.consumer-law-the-rest-of-part-ivf-reaches-banking-on-2027-03-31", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.consumer-law-the-six-scams-prevention-framework-principles", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:role.auspayplus", "id": "role.auspayplus", "rail": "au-npp", "class": "Role", "name": "Australian Payments Plus (AP+)", "summary": "The holding company above the scheme operator. It also owns the operators of eftpos and BPAY, and it publishes one set of scheme rules that is incorporated by reference into each scheme's own product rules. It is the publisher of the payment initiation guidance that carries the only reason code list the authority puts out. A rule that binds NPPA does not bind AP+ and the two are not interchangeable in a citation.", "kind": "operator", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-payment-initiation-messages-v4", "section": "cover, terms of use and document control", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.auspayplus-payto-faqs", "section": "the FAQ pages as a whole", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links; ASIC's ePayments Code of 2 June 2022; the Scams Prevention Framework Act 2025 and the Regulated Sectors Designation 2026; the Reserve Bank's About RITS page; and Australian Payments Plus's PayTo FAQs and payment initiation guidance v4.0. All read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-payment-initiation-messages-v4", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "The document's cover, terms of use and document control confirm AP+ and NPPA as its publishers, with the acceptance block covering warranty and intellectual property terms rather than restricting citation." }, { "source": "au-npp:src.auspayplus-payto-faqs", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "The FAQ pages as a whole confirm AP+ publishes consumer-facing PayTo guidance describing agreement management and the migration of direct debits to PayTo." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:role.clearing-participant", "id": "role.clearing-participant", "rail": "au-npp", "class": "Role", "name": "Clearing Participant", "summary": "A participant that connects directly to the infrastructure and clears its own payments, but that the Reserve Bank has not authorised to use the Fast Settlement Service. It settles instead through a private arrangement with another participant. It carries the connection requirements of a Full Participant without the settlement authorisation.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 4.4 and the definition of Clearing Participant", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links; ASIC's ePayments Code of 2 June 2022; the Scams Prevention Framework Act 2025 and the Regulated Sectors Designation 2026; the Reserve Bank's About RITS page; and Australian Payments Plus's PayTo FAQs and payment initiation guidance v4.0. All read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 4.4 confirms a Clearing Participant must meet the Full Participant connection requirements and enter a proprietary arrangement with another NPP Participant for settlement under Part 7, and the definition of Clearing Participant confirms it connects directly without RBA authorisation to use the FSS." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.limits-nppa-may-direct-value-limits-for-capacity", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.participants-three-classes-and-two-capabilities", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.settlement-a-clearing-participant-settles-through-another-participant", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.settlement-contingency-and-indeterminate-status-sit-in-the-procedures", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.settlement-the-gateway-generates-a-settlement-request-automatically", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:role.confirmed-data-holder", "id": "role.confirmed-data-holder", "rail": "au-npp", "class": "Role", "name": "Confirmed Data Holder and CoP Data Requestor", "summary": "The two Confirmation of Payee positions in which participation is compulsory for a participant and its sponsored identified institutions: holding the confirmed account name data the central matching service checks against, and asking for a check on a payer's behalf. Holding observed data is optional, and so is a connected institution's participation.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 18.1(a) and (b)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links; ASIC's ePayments Code of 2 June 2022; the Scams Prevention Framework Act 2025 and the Regulated Sectors Designation 2026; the Reserve Bank's About RITS page; and Australian Payments Plus's PayTo FAQs and payment initiation guidance v4.0. All read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 18.1(b)(i) confirms participation as a Confirmed Data Holder is mandatory for NPP Participants and their sponsored Identified Institutions, and Regulation 18.1(a) confirms the Confirmation of Payee Service enables central name matching against Confirmed Data Records." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.decision-points-the-payer-acts-on-a-confirmation-of-payee-outcome", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:role.connected-institution", "id": "role.connected-institution", "rail": "au-npp", "class": "Role", "name": "Connected Institution", "summary": "A body corporate that connects directly to the infrastructure but has no right under the rules to send clearing or settlement messages. It may send and receive non value messages, and it may take part in the Mandated Payments Service as a payment initiator or for one, creating mandate records and sending payment initiation requests. It cannot move money itself.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 4.1(b)(ii), 4.6 and 17.5(e)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links; ASIC's ePayments Code of 2 June 2022; the Scams Prevention Framework Act 2025 and the Regulated Sectors Designation 2026; the Reserve Bank's About RITS page; and Australian Payments Plus's PayTo FAQs and payment initiation guidance v4.0. All read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulations 4.1(b)(ii) and 4.6 confirm a Connected Institution connects directly to the infrastructure for sending and receiving Non-Value Messages, and Regulation 17.5(e) confirms it has no right to submit clearing or settlement messages but may participate in the Mandated Payments Service as, or for, a Payment Initiator." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.limits-nppa-may-direct-value-limits-for-capacity", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-participation-is-mandatory-for-a-payer-participant", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.participants-a-connected-institution-cannot-clear", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.participants-the-rules-are-a-contract-under-seal", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:role.full-participant", "id": "role.full-participant", "rail": "au-npp", "class": "Role", "name": "Full Participant", "summary": "A participant that connects directly to the infrastructure to send and receive payments and non value messages, and that the Reserve Bank has authorised to use the Fast Settlement Service. It must be the Reserve Bank or an authorised deposit-taking institution, must hold a registered eight character bank identifier code, must contract with at least two vendor network partners, and must complete onboarding with the network provider. It is the only class that has both capabilities.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 4.2(a), 4.3(a) to (f) and 7.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links; ASIC's ePayments Code of 2 June 2022; the Scams Prevention Framework Act 2025 and the Regulated Sectors Designation 2026; the Reserve Bank's About RITS page; and Australian Payments Plus's PayTo FAQs and payment initiation guidance v4.0. All read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulations 4.2(a), 4.3(a) to (f) and 7.1 confirm a Full Participant must be the RBA or an ADI, be a SWIFT user and BIC8 Holder, hold Network Agreements with at least two Vendor Network Partners, complete SWIFT onboarding, and be authorised by the RBA to use the FSS." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.limits-nppa-may-direct-value-limits-for-capacity", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.participants-the-rules-are-a-contract-under-seal", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.participants-three-classes-and-two-capabilities", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.settlement-authorisation-by-the-rba-is-required-to-settle", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.settlement-contingency-and-indeterminate-status-sit-in-the-procedures", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.settlement-esa-funds-split-between-fss-and-everything-else", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.settlement-per-payment-rtgs-across-exchange-settlement-accounts", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.settlement-the-gateway-generates-a-settlement-request-automatically", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:role.identified-institution", "id": "role.identified-institution", "rail": "au-npp", "class": "Role", "name": "Identified Institution", "summary": "An institution that does not connect to the platform and reaches it through a sponsoring participant. Most of the institutions reachable on this rail are in this position. The sponsor is answerable for the identified institution's compliance with the rules that are written for participants.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 6.1(d)(i)(B), 17.1(d) and the definition of Sponsor", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links; ASIC's ePayments Code of 2 June 2022; the Scams Prevention Framework Act 2025 and the Regulated Sectors Designation 2026; the Reserve Bank's About RITS page; and Australian Payments Plus's PayTo FAQs and payment initiation guidance v4.0. All read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "The definitions of Identified Institution and Sponsor and Regulation 6.1(d)(i)(B) confirm an Identified Institution does not connect to the infrastructure and reaches it through a Sponsor's clearing or settlement services, with the Sponsor responsible for satisfying itself the Identified Institution has a compliance framework." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.participants-most-institutions-reach-the-platform-through-a-sponsor", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:role.initiating-participant", "id": "role.initiating-participant", "rail": "au-npp", "class": "Role", "name": "Initiating Participant", "summary": "The participant or connected institution that sends a mandate payment initiation request on behalf of the party named in the mandate. It must not send one unless the mandate is active, it is answerable for the request being properly built and consistent with the mandate's terms, and it indemnifies the scheme operator and every other participant against substantiated mandate claims arising from what it sends.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 17.1(d), 17.8(a) and (b), 17.9 and 17.10(a)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links; ASIC's ePayments Code of 2 June 2022; the Scams Prevention Framework Act 2025 and the Regulated Sectors Designation 2026; the Reserve Bank's About RITS page; and Australian Payments Plus's PayTo FAQs and payment initiation guidance v4.0. All read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulations 17.1(d) and 17.8(a) and (b) confirm the Initiating Participant is the NPP Participant or Connected Institution that submits Mandate Payment Initiation Requests, must not do so unless the Mandate is Active, and is responsible for each request being properly constructed and consistent with the Mandate's terms; Regulation 17.10(a) confirms its indemnity against Mandate Claims." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:exc.mandate-claim", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.liability-the-initiating-participant-indemnifies-against-mandate-claims", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-a-request-may-not-be-sent-unless-the-mandate-is-active", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-an-authorised-mandate-claim-is-deemed-substantiated-by-the-record", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-data-is-confidential-to-the-parties", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-five-days-before-a-migrated-mandate-may-be-used", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-indemnity-settlement-timeframes-are-not-public", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-the-record-is-evidence-of-quantum-frequency-and-beneficiary", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:role.mps-user", "id": "role.mps-user", "rail": "au-npp", "class": "Role", "name": "MPS User", "summary": "The business or provider the payer authorises in a PayTo mandate, sponsored into the service by a participant or by a sponsored identified institution. It is either a creditor collecting payments for itself or a payment initiator moving money on somebody's instruction. Its sponsor assesses it, approves it, oversees it and carries the risk of what it does.", "kind": "party", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 17.1(b) and (e), and 17.5(a) to (d)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links; ASIC's ePayments Code of 2 June 2022; the Scams Prevention Framework Act 2025 and the Regulated Sectors Designation 2026; the Reserve Bank's About RITS page; and Australian Payments Plus's PayTo FAQs and payment initiation guidance v4.0. All read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 17.1(b) and (e) confirm an MPS User is a Creditor or Payment Initiator authorised to participate in the MPS by its sponsor, and Regulation 17.5(a) to (d) confirm the sponsoring participant is responsible for approving, assessing and taking full risk on the MPS Users it sponsors." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:mandate.authorised-payment-mandate", "type": "given_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:mandate.migrated-ddr-mandate", "type": "given_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.liability-a-sponsor-takes-full-risk-on-the-users-it-sponsors", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-a-mandate-is-a-record-in-the-scheme-operators-database", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-a-migrated-mandate-is-created-without-a-consent-step", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-an-amount-or-frequency-change-comes-from-the-business", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-fourteen-days-notice-before-a-migrated-mandate-is-created", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:role.nppa", "id": "role.nppa", "rail": "au-npp", "class": "Role", "name": "NPP Australia Limited (NPPA)", "summary": "The scheme operator and the body that writes the rules. It established and runs the NPP Basic Infrastructure, the Addressing Service behind PayID, the Mandate Management Service behind PayTo and the Confirmation of Payee service, and it sets the message usage guidelines, the configurable timeout values, the mandatory compliance requirements and the technical minimums for every one of them. Its rules take effect as a contract under seal between it and every participant, connected institution and overlay service provider. It is a subsidiary of Australian Payments Plus and it is not the same body as its parent.", "kind": "operator", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 4.2(d), 8.1(a), 17.1(g) and (h), 18.1(c) and (d)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links; ASIC's ePayments Code of 2 June 2022; the Scams Prevention Framework Act 2025 and the Regulated Sectors Designation 2026; the Reserve Bank's About RITS page; and Australian Payments Plus's PayTo FAQs and payment initiation guidance v4.0. All read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulations 4.2(d), 8.1(a) and 17.1(g) and (h) confirm NPPA writes the Regulations, establishes and operates the MMS and MPS, and holds the powers to define MMS and MPS technical standards; Regulation 18.1(c) and (d) confirm the same for the Confirmation of Payee Service." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.decision-points-the-payer-acts-on-a-confirmation-of-payee-outcome", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.decision-points-the-payer-participant-screens-before-it-sends", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.hours-clearing-and-settlement-run-24-hours-every-day", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.hours-response-timeout-values-are-not-public", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.hours-service-availability-targets-are-not-public", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.liability-the-initiating-participant-indemnifies-against-mandate-claims", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.limits-nppa-may-direct-value-limits-for-capacity", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-a-mandate-is-a-record-in-the-scheme-operators-database", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-data-is-confidential-to-the-parties", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.messages-iso-20022-from-launch", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.participants-no-public-list-by-class-exists", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.participants-the-rules-are-a-contract-under-seal", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:role.overlay-service-provider", "id": "role.overlay-service-provider", "rail": "au-npp", "class": "Role", "name": "Overlay Service Provider", "summary": "A provider approved to run a service on top of the platform for subscribing participants. Overlay rules may add requirements but may not contradict the core clearing and settlement rules, and an overlay payment carries its own identifier in the message header. Osko is the service everyone names, and the rulebook's own definitions make an Osko payment a basic single credit transfer rather than an overlay payment, which is an ambiguity the public text does not settle.", "kind": "service_provider", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 4.1(b)(iii), 17.3(b) and the definitions of OS Payment, Basic Single Credit Transfer and Osko Payment", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links; ASIC's ePayments Code of 2 June 2022; the Scams Prevention Framework Act 2025 and the Regulated Sectors Designation 2026; the Reserve Bank's About RITS page; and Australian Payments Plus's PayTo FAQs and payment initiation guidance v4.0. All read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 4.1(b)(iii) confirms an Overlay Service Provider is entitled to provide approved Overlay Services, Regulation 17.3(b) confirms OS Rules may not be inconsistent with the NPP Core Clearing and Settlement Rules, and the definitions of OS Payment, Basic Single Credit Transfer and Osko Payment confirm the overlay-payment classification question the record leaves open." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.mandate-participation-is-mandatory-for-a-payer-participant", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.participants-the-rules-are-a-contract-under-seal", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:role.payee-customer", "id": "role.payee-customer", "rail": "au-npp", "class": "Role", "name": "Payee Customer", "summary": "The account holder the money is going to. Whether and when the payee customer sees a payment before it settles, and how they are told about it, is largely the receiving institution's own matter above a minimum set in the procedures, and what the institution tells them about a payment being sent back is its own matter too.", "kind": "party", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 6.3(b), 6.5(c) note and 6.6 note", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links; ASIC's ePayments Code of 2 June 2022; the Scams Prevention Framework Act 2025 and the Regulated Sectors Designation 2026; the Reserve Bank's About RITS page; and Australian Payments Plus's PayTo FAQs and payment initiation guidance v4.0. All read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 6.3(b) confirms the Payee Participant may set its own service level standards for applying Cleared BSCTs to accounts and notifying Payees beyond the minimum NPP Procedures requirement, and the notes to Regulations 6.5(c) and 6.6 confirm notification of, or authorisation for, a return is otherwise a proprietary matter for the Payee Participant." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:role.payee-participant", "id": "role.payee-participant", "rail": "au-npp", "class": "Role", "name": "Payee Participant", "summary": "The participant on the receiving side. It must answer every clearing request inside the configured timeout, either accepting or rejecting with a reason code, and its acceptance is what makes a payment cleared. Nothing obliges it to put a cleared payment on an account before settlement. It is the party that assesses a request to send a payment back, and whether it must, may or must if satisfied depends on which of four defined kinds of wrong payment it is.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 6.2(b) and (f)(i), 6.3(a) and (b), 6.5(a) to (c) and 6.6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links; ASIC's ePayments Code of 2 June 2022; the Scams Prevention Framework Act 2025 and the Regulated Sectors Designation 2026; the Reserve Bank's About RITS page; and Australian Payments Plus's PayTo FAQs and payment initiation guidance v4.0. All read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulations 6.2(b) and (f)(i), 6.3(a) and (b), 6.5(a) to (c) and 6.6 confirm the Payee Participant answers every Clearing Request within the configured timeout, its acceptance is what clears a payment, it is not obliged to apply a payment to an account before settlement, and it carries the differing return obligations for Mistaken, Misdirected, Duplicate and Error Payments and unsolicited returns." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:exc.clearing-rejection", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:exc.clearing-rejection", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:exc.duplicate-or-error-payment-return-request", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:exc.misdirected-payment-return-request", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:exc.mistaken-payment-return-request", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:exc.unsolicited-return", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:exc.unsolicited-return", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.decision-points-the-payee-participant-accepts-or-rejects", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.finality-a-cleared-payment-the-fss-rejects-is-void", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.finality-cleared-means-the-payee-participant-accepted-it", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.finality-irrevocable-on-settlement-in-the-fss", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.hours-response-timeout-values-are-not-public", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.hours-service-availability-targets-are-not-public", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.limits-a-zero-value-payment-is-forbidden", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.messages-a-rejected-clearing-request-carries-a-reason-code", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.messages-a-retry-and-a-replay-are-not-the-same-thing", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.recall-a-duplicate-or-error-payment-return-is-discretionary", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.recall-a-misdirected-payment-is-returned-if-the-payee-participant-is-satisfied", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.recall-a-mistaken-payment-must-be-assessed-and-returned-if-needed", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.recall-a-request-for-payment-return-is-a-request-not-a-right", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.recall-the-payer-participant-indemnifies-a-good-faith-return", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.return-a-return-is-a-new-payment-going-the-other-way", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.return-a-zero-value-return-is-forbidden", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.return-an-unsolicited-return-is-the-payee-participants-own-choice", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.return-only-a-cleared-payment-may-be-returned", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.return-windows-and-deadlines-are-not-public", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:role.payer-customer", "id": "role.payer-customer", "rail": "au-npp", "class": "Role", "name": "Payer Customer", "summary": "The account holder whose account the money leaves. On an ordinary payment the payer customer chooses the destination, by account details or by PayID, and lives with the consequences of getting it wrong. On PayTo the payer customer is the party that authorises the mandate, the party the mandate record is evidence about, and the party who can pause, resume, amend or cancel it in their own banking app.", "kind": "party", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 17.1(b), 17.6(c)(vii) and 17.10(c)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.auspayplus-payto-faqs", "section": "what a PayTo agreement is, and managing agreements", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links; ASIC's ePayments Code of 2 June 2022; the Scams Prevention Framework Act 2025 and the Regulated Sectors Designation 2026; the Reserve Bank's About RITS page; and Australian Payments Plus's PayTo FAQs and payment initiation guidance v4.0. All read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 17.1(b) confirms the Payer Customer gives the Mandate's authorisation, Regulation 17.6(c)(vii) confirms their right to view, suspend, cancel and amend a Mandate, and Regulation 17.10(c) confirms what counts as an unauthorised Mandate Payment from the Payer Customer's perspective." }, { "source": "au-npp:src.auspayplus-payto-faqs", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "The FAQ pages confirm the payer manages a PayTo agreement, including pausing, resuming and cancelling it, in their own online banking." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:exc.mistaken-internet-payment", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:exc.spf-scam-complaint", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:exc.unauthorised-transaction-claim", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:mandate.authorised-payment-mandate", "type": "given_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:mandate.debtor-payment-arrangement", "type": "given_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:mandate.migrated-ddr-mandate", "type": "given_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.decision-points-the-payer-acts-on-a-confirmation-of-payee-outcome", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.decision-points-the-payer-customer-authorises-pauses-or-cancels-a-mandate", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.decision-points-the-payer-participant-may-seek-confirmation-of-a-migrated-mandate", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.liability-a-deceived-payer-is-not-an-unauthorised-transaction", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.liability-a-scam-victim-recovers-by-proving-a-contravention", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.liability-australia-has-no-mandatory-scam-reimbursement-rule", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.liability-the-holder-is-liable-where-the-subscriber-proves-contribution", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.liability-the-holder-is-not-liable-where-an-identifier-alone-can-pay", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.liability-the-residual-cap-is-150-dollars", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-a-mandate-is-a-record-in-the-scheme-operators-database", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-a-mandate-may-be-ported-to-another-participant", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-an-amount-or-frequency-change-comes-from-the-business", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-authorisation-is-delivered-in-near-real-time", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-fourteen-days-notice-before-a-migrated-mandate-is-created", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-the-payer-customer-can-view-suspend-cancel-and-amend", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-the-payer-participant-keeps-processing-pending-word", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.refund-an-on-screen-warning-is-required-but-not-for-payid", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.refund-the-scheme-gives-a-customer-no-refund-right", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:role.payer-participant", "id": "role.payer-participant", "rail": "au-npp", "class": "Role", "name": "Payer Participant", "summary": "The participant on the paying side of a payment. It builds and sends the clearing request, it cannot cancel or recall it once the message is in its own gateway, its gateway generates the settlement request automatically, it decides alone whether to replay or retry a payment the settlement service rejected, and it is the party that asks for a payment back. It is also the party that records a customer's authorisation of a PayTo mandate and the party that brings a mandate claim on that customer's behalf.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 6.2(a) to (f), 6.4(c), 6.5, 17.6(c) and 17.10(c)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links; ASIC's ePayments Code of 2 June 2022; the Scams Prevention Framework Act 2025 and the Regulated Sectors Designation 2026; the Reserve Bank's About RITS page; and Australian Payments Plus's PayTo FAQs and payment initiation guidance v4.0. All read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulations 6.2(a) to (f) confirm the Payer Participant cannot cancel or recall a Clearing Request once sent, its gateway auto-generates the Settlement Request, and it alone decides whether to Replay or Retry a voided payment; Regulation 6.4(c) confirms it bears full liability for a settled Duplicate Payment or its own error; Regulations 6.5 and 17.6(c) and 17.10(c) confirm its roles in requesting returns and in Mandate Claims." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:exc.duplicate-or-error-payment-return-request", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:exc.mandate-claim", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:exc.misdirected-payment-return-request", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:exc.mistaken-payment-return-request", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:exc.payment-initiation-rejection", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:exc.payment-initiation-rejection", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:exc.settlement-rejection", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:mandate.debtor-payment-arrangement", "type": "given_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.decision-points-the-payer-customer-authorises-pauses-or-cancels-a-mandate", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.decision-points-the-payer-participant-may-seek-confirmation-of-a-migrated-mandate", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.decision-points-the-payer-participant-screens-before-it-sends", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.finality-a-cleared-payment-the-fss-rejects-is-void", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.finality-cleared-means-the-payee-participant-accepted-it", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.finality-irrevocable-on-settlement-in-the-fss", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.finality-no-cancel-or-recall-once-the-message-is-in-the-gateway", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.finality-the-payer-participant-alone-decides-to-replay-or-retry", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.hours-response-timeout-values-are-not-public", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.limits-a-zero-value-payment-is-forbidden", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.limits-participants-set-their-own-customer-limits", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.limits-the-scheme-sets-no-maximum-value", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-a-mandate-may-be-ported-to-another-participant", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-a-migrated-mandate-claim-is-deemed-substantiated", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-a-migrated-mandate-is-created-without-a-consent-step", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-a-request-may-not-be-sent-unless-the-mandate-is-active", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-an-authorised-mandate-claim-is-deemed-substantiated-by-the-record", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-authorisation-is-delivered-in-near-real-time", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-data-is-confidential-to-the-parties", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-five-days-before-a-migrated-mandate-may-be-used", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-indemnity-settlement-timeframes-are-not-public", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-participation-is-mandatory-for-a-payer-participant", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-the-payer-customer-can-view-suspend-cancel-and-amend", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-the-payer-participant-keeps-processing-pending-word", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-the-record-is-evidence-of-quantum-frequency-and-beneficiary", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.messages-a-rejected-mandate-payment-request-carries-a-reason-code", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.messages-a-retry-and-a-replay-are-not-the-same-thing", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.messages-four-status-code-values-on-the-initiation-leg", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.recall-a-duplicate-or-error-payment-return-is-discretionary", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.recall-a-misdirected-payment-is-returned-if-the-payee-participant-is-satisfied", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.recall-a-mistaken-payment-must-be-assessed-and-returned-if-needed", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.recall-a-request-for-payment-return-is-a-request-not-a-right", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.recall-the-payer-participant-carries-its-own-customers-loss", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.recall-the-payer-participant-indemnifies-a-good-faith-return", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.recall-there-is-no-recall-and-no-cancellation-message", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.return-windows-and-deadlines-are-not-public", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.settlement-contingency-and-indeterminate-status-sit-in-the-procedures", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.settlement-the-gateway-generates-a-settlement-request-automatically", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC02", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC03", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC05", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC06", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC07", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC13", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC14", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC15", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AG01", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AG03", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AGNT", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM01", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM02", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM03", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM04", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM06", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM09", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM12", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM19", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM21", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:BE06", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:BE08", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:BE22", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:CH20", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:CH21", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:CURR", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:DT02", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:DT04", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:FF10", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:MD01", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:NARR", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:NAUT", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:TD03", "type": "returned_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:role.payment-initiator", "id": "role.payment-initiator", "rail": "au-npp", "class": "Role", "name": "Payment Initiator", "summary": "A payment service provider authorised by the payer to start payments from the payer's account, whether it acts for the payer or for a business. It may be sponsored into the service by a participant, as a user of the service, or by a connected institution, and a mandate held for it can be moved to a different participant or connected institution on its instruction.", "kind": "service_provider", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 17.1(e)(iii), 17.5(e) and 17.5(f)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links; ASIC's ePayments Code of 2 June 2022; the Scams Prevention Framework Act 2025 and the Regulated Sectors Designation 2026; the Reserve Bank's About RITS page; and Australian Payments Plus's PayTo FAQs and payment initiation guidance v4.0. All read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 17.1(e)(iii) confirms a Payment Initiator is a payment service provider authorised by the Payer Customer to initiate payments from the Payer Customer's account, whether acting for the payer or for a Creditor, and Regulation 17.5(e) and (f) confirm it may be sponsored by an NPP Participant or a Connected Institution and its Mandates may be ported on its instruction." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.mandate-a-mandate-may-be-ported-to-another-participant", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:role.rba-esa-provider", "id": "role.rba-esa-provider", "rail": "au-npp", "class": "Role", "name": "Reserve Bank of Australia, as provider of exchange settlement accounts", "summary": "The Reserve Bank holds the exchange settlement accounts across which NPP payments settle. A participant in the Fast Settlement Service may split the funds on its account between an amount available to that service and an amount available to everything else. This is a different position from operating the service and from being a participant in the platform, and the Reserve Bank holds all three.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "au-npp:src.rba-about-rits", "section": "About RITS, on the allocation of exchange settlement account funds", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 7.3(b) and the definition of ESA", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links; ASIC's ePayments Code of 2 June 2022; the Scams Prevention Framework Act 2025 and the Regulated Sectors Designation 2026; the Reserve Bank's About RITS page; and Australian Payments Plus's PayTo FAQs and payment initiation guidance v4.0. All read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.rba-about-rits", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "The RBA's About RITS page confirms an ESA holder participating in the FSS may allocate its funds between an amount available for FSS settlement and an amount for all other transactions." }, { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 7.3(b) confirms settlement is by debiting and crediting the ESAs of the participants responsible, and the definition of ESA confirms it as an account an NPP Participant maintains with the RBA for settling obligations including those under these Regulations." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.settlement-esa-funds-split-between-fss-and-everything-else", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.settlement-per-payment-rtgs-across-exchange-settlement-accounts", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:role.rba-fss-operator", "id": "role.rba-fss-operator", "rail": "au-npp", "class": "Role", "name": "Reserve Bank of Australia, as operator of the Fast Settlement Service", "summary": "The Reserve Bank built and runs the Fast Settlement Service as a component of RITS, which it owns and operates. The service tests whether the paying institution has the funds on its settlement account and either settles the payment or rejects it, individually, around the clock. It is also the body that authorises a participant to use the service at all. This is one of three separate positions the Reserve Bank holds on this rail.", "kind": "operator", "relations": [ { "type": "sourced_from", "to": "au-npp:src.rba-about-rits", "section": "About RITS and Real-time Gross Settlement", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 7.1 and 7.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links; ASIC's ePayments Code of 2 June 2022; the Scams Prevention Framework Act 2025 and the Regulated Sectors Designation 2026; the Reserve Bank's About RITS page; and Australian Payments Plus's PayTo FAQs and payment initiation guidance v4.0. All read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.rba-about-rits", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "The RBA's About RITS page confirms the RBA built and operates the FSS as part of RITS, and that the FSS tests whether the paying ESA holder has sufficient funds and settles or rejects the payment accordingly." }, { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulations 7.1 and 7.3 confirm Full and Settlement Participants must be authorised by the RBA to use the FSS and that settlement occurs via the FSS by debiting and crediting ESAs." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:exc.settlement-rejection", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.finality-rtgs-settlement-is-final-under-the-netting-act", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.hours-clearing-and-settlement-run-24-hours-every-day", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.settlement-authorisation-by-the-rba-is-required-to-settle", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.settlement-no-liquidity-management-features", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.settlement-the-fss-tests-funds-and-settles-or-rejects", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:role.receiving-adi", "id": "role.receiving-adi", "rail": "au-npp", "class": "Role", "name": "Receiving ADI (ePayments Code)", "summary": "The institution whose customer received the payment. What it must do turns on when the payment was reported and on whether the money is still there: return it, hold it and give the recipient a chance to show entitlement, ask the recipient for consent, or weigh the two customers' interests and decide how much to pursue.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "au-npp:src.epayments-code-2022", "section": "clauses 25.2, 29.2(b), 30.2, 31.2 to 31.5, 32.2 and 34.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links; ASIC's ePayments Code of 2 June 2022; the Scams Prevention Framework Act 2025 and the Regulated Sectors Designation 2026; the Reserve Bank's About RITS page; and Australian Payments Plus's PayTo FAQs and payment initiation guidance v4.0. All read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.epayments-code-2022", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Clauses 25.2, 29.2(b), 30.2, 31.2 to 31.5, 32.2 and 34.2 confirm the receiving ADI's obligations vary by reporting tier: acknowledging and answering within 5 business days, returning within 5 to 10 business days where funds are sufficient and reported within 10 business days, investigating and holding funds where reported between 10 business days and 7 months, seeking consent where reported after 7 months, and exercising a weighed discretion where funds are insufficient." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:exc.mistaken-internet-payment", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.refund-reported-after-7-months-only-with-consent", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.refund-reported-between-10-business-days-and-7-months", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.refund-reported-within-10-business-days-the-money-comes-back", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.refund-the-receiving-adi-answers-within-5-business-days", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.refund-where-the-funds-are-short-the-receiving-adi-weighs-the-two-customers", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:role.registering-participant", "id": "role.registering-participant", "rail": "au-npp", "class": "Role", "name": "Registering Participant", "summary": "The participant that registers, maintains and deregisters a PayID in the Addressing Service. It warrants that it is authorised to register the entry, that the holder behind the alias is authorised to operate the account, and that what it registered is current, accurate and complete, and it must disable and deregister an alias it reasonably suspects of fraudulent use. A payment that lands in the wrong account because this went wrong is a misdirected payment, which is its own defined term with its own indemnity.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 8.3(b) and (c), and the definition of Misdirected Payment", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links; ASIC's ePayments Code of 2 June 2022; the Scams Prevention Framework Act 2025 and the Regulated Sectors Designation 2026; the Reserve Bank's About RITS page; and Australian Payments Plus's PayTo FAQs and payment initiation guidance v4.0. All read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 8.3(b) confirms the Registering Participant's duties to control alias selection, follow the Procedures' registration requirements, and keep Alias Information accurate and current; Regulation 8.3(c) confirms its warranties on authorisation and account holder authority; the definition of Misdirected Payment confirms a payment misdirected because of the Registering Participant's own registration failure." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.liability-a-registering-participant-indemnifies-a-misdirected-payment", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.recall-a-misdirected-payment-is-returned-if-the-payee-participant-is-satisfied", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:role.sending-adi", "id": "role.sending-adi", "rail": "au-npp", "class": "Role", "name": "Sending ADI (ePayments Code)", "summary": "The institution whose customer made the payment, in the ePayments Code's mistaken internet payment process. It investigates the report, asks the other institution for the money back, returns it to its customer when it arrives, and must tell the customer the outcome in writing. Non cooperation by the other side is explicitly not a reason it can offer for failing its own obligations.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "au-npp:src.epayments-code-2022", "section": "clauses 25.2, 29.1 to 29.4, 35.1 and 36.5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links; ASIC's ePayments Code of 2 June 2022; the Scams Prevention Framework Act 2025 and the Regulated Sectors Designation 2026; the Reserve Bank's About RITS page; and Australian Payments Plus's PayTo FAQs and payment initiation guidance v4.0. All read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.epayments-code-2022", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Clauses 25.2, 29.1 to 29.4 and 35.1 confirm the sending ADI investigates a reported mistaken internet payment, requests return from the receiving ADI, returns funds to its own customer, keeps records, and must inform the customer of the outcome in writing within 30 business days; clause 36.5 confirms the receiving ADI's non-cooperation is not a relevant factor in judging the sending ADI's own compliance." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.consumer-law-afca-hears-a-mistaken-payment-complaint", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.refund-reported-between-10-business-days-and-7-months", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.refund-reported-within-10-business-days-the-money-comes-back", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.refund-the-outcome-in-writing-within-30-business-days", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.refund-the-sending-adi-must-investigate-and-ask-within-5-business-days", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:role.settlement-participant", "id": "role.settlement-participant", "rail": "au-npp", "class": "Role", "name": "Settlement Participant", "summary": "A participant that does not connect to the infrastructure at all but that the Reserve Bank has authorised to use the Fast Settlement Service. It is the mirror image of a Clearing Participant, and the rulebook says in terms that it need not be an authorised deposit-taking institution: a body corporate carrying on business through a permanent establishment in Australia is enough. Australian access is wider than banks only in this one direction.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 4.2(a), 4.5 and the definition of Settlement Participant", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links; ASIC's ePayments Code of 2 June 2022; the Scams Prevention Framework Act 2025 and the Regulated Sectors Designation 2026; the Reserve Bank's About RITS page; and Australian Payments Plus's PayTo FAQs and payment initiation guidance v4.0. All read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 4.2(a) and 4.5 confirm a Settlement Participant need not connect directly, must be authorised by the RBA to use the FSS, and for the avoidance of doubt need not be an ADI." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.participants-a-settlement-participant-need-not-be-an-adi", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.participants-three-classes-and-two-capabilities", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.settlement-authorisation-by-the-rba-is-required-to-settle", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.settlement-esa-funds-split-between-fss-and-everything-else", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.settlement-per-payment-rtgs-across-exchange-settlement-accounts", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:role.spf-regulated-entity", "id": "role.spf-regulated-entity", "rail": "au-npp", "class": "Role", "name": "Regulated entity under the Scams Prevention Framework", "summary": "An entity providing a service the Minister has designated into a regulated sector. For banking that means a service an authorised deposit-taking institution provides in the course of its banking business in Australia. A regulated entity carries the six framework principles, each backed by civil penalties, and is the person a scam victim sues if a contravention caused their loss.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "au-npp:src.spf-regulated-sectors-designation-2026", "section": "section 11", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.scams-prevention-framework-act-2025", "section": "Part IVF Division 2, and section 58FZC", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links; ASIC's ePayments Code of 2 June 2022; the Scams Prevention Framework Act 2025 and the Regulated Sectors Designation 2026; the Reserve Bank's About RITS page; and Australian Payments Plus's PayTo FAQs and payment initiation guidance v4.0. All read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.spf-regulated-sectors-designation-2026", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Section 11 confirms a covered banking service is a service an ADI provides in carrying on its banking business in Australia, or a purchased payment facility it provides, designated as a regulated sector." }, { "source": "au-npp:src.scams-prevention-framework-act-2025", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Part IVF Division 2 confirms the six SPF principles bind a regulated entity as civil penalty provisions, and section 58FZC confirms a victim may recover loss caused by a regulated entity's contravention of one of those provisions." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:exc.spf-scam-complaint", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.consumer-law-external-dispute-resolution-membership-from-2026-09-01", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.consumer-law-internal-dispute-resolution-and-apportionment-guidelines", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.consumer-law-the-rest-of-part-ivf-reaches-banking-on-2027-03-31", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.consumer-law-the-six-scams-prevention-framework-principles", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.liability-a-scam-victim-recovers-by-proving-a-contravention", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.liability-australia-has-no-mandatory-scam-reimbursement-rule", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:role.sponsor", "id": "role.sponsor", "rail": "au-npp", "class": "Role", "name": "Sponsor", "summary": "A participant that provides clearing or settlement services to an identified institution. It must satisfy itself that the institution it sponsors has a framework for sanctions and know your customer compliance, it approves and takes full risk on the users it sponsors into the Mandated Payments Service, and it carries the indemnity for mandate claims arising from what those users do.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 6.1(d), 17.5(d) and 17.10(a)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links; ASIC's ePayments Code of 2 June 2022; the Scams Prevention Framework Act 2025 and the Regulated Sectors Designation 2026; the Reserve Bank's About RITS page; and Australian Payments Plus's PayTo FAQs and payment initiation guidance v4.0. All read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 6.1(d) confirms a sponsoring participant is responsible for satisfying itself that each Identified Institution it sponsors has sanctions and KYC compliance frameworks; Regulation 17.5(d) confirms it takes full risk on approving and sponsoring MPS Users; Regulation 17.10(a) confirms its indemnity obligations arising from Mandate Claims." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.decision-points-the-payer-participant-screens-before-it-sends", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.liability-a-sponsor-takes-full-risk-on-the-users-it-sponsors", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-a-migrated-mandate-claim-is-deemed-substantiated", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-a-migrated-mandate-is-created-without-a-consent-step", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-fourteen-days-notice-before-a-migrated-mandate-is-created", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.participants-most-institutions-reach-the-platform-through-a-sponsor", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:role.subscriber", "id": "role.subscriber", "rail": "au-npp", "class": "Role", "name": "Subscriber to the ePayments Code", "summary": "An institution that has chosen to be bound by the ePayments Code. Everything the Code requires is an obligation of a subscriber and of nobody else, which is why a record that says Australian law requires, where it means the Code requires of its subscribers, is wrong. Which institutions subscribe is not held here.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "au-npp:src.epayments-code-2022", "section": "the Code as a whole; Chapter E applies to subscribers that are authorised deposit-taking institutions, clause 25.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links; ASIC's ePayments Code of 2 June 2022; the Scams Prevention Framework Act 2025 and the Regulated Sectors Designation 2026; the Reserve Bank's About RITS page; and Australian Payments Plus's PayTo FAQs and payment initiation guidance v4.0. All read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.epayments-code-2022", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "The Code throughout expresses its obligations as those of a subscriber, and clause 25.1 confirms Chapter E's mistaken internet payment obligations apply to subscribers that are ADIs, other than providers of purchased payment facilities." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:exc.unauthorised-transaction-claim", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.consumer-law-the-epayments-code-is-voluntary", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.liability-a-deceived-payer-is-not-an-unauthorised-transaction", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.liability-the-holder-is-liable-where-the-subscriber-proves-contribution", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.liability-the-holder-is-not-liable-where-an-identifier-alone-can-pay", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.liability-the-residual-cap-is-150-dollars", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.refund-an-on-screen-warning-is-required-but-not-for-payid", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.consumer-law-afca-hears-a-mistaken-payment-complaint", "id": "rule.consumer-law-afca-hears-a-mistaken-payment-complaint", "rail": "au-npp", "class": "Rule", "name": "The external dispute resolution scheme hears a mistaken payment complaint about the sending institution", "statement": "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.", "rests_on": "guidance", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "au-npp:src.epayments-code-2022", "section": "clauses 36.1 to 36.5 and clause 15.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.sending-adi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.afca", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.mistaken-internet-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "ASIC's ePayments Code as published 2 June 2022, at the clauses named in the record's sourced_from link, read 2026-09-21.", "confidence": "high" }, "currency": { "effective_since": "2022-06-02", "effective_to": null, "effective_note": "Drafted 2026-09-21 from ASIC's own current text of the ePayments Code. The Code is voluntary and binds subscribers only; which institutions subscribe was not established here.", "source_edition": "ePayments Code as published by ASIC on 2 June 2022, read 2026-09-21.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.epayments-code-2022", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Clauses 36.1 to 36.5 confirm a user may complain to the sending ADI about how a mistaken payment report was handled, that the sending ADI must deal with it under internal dispute resolution and must not require the user to complain to the receiving ADI, that an unsatisfied user must be able to take the complaint to AFCA, and that both ADIs must cooperate with AFCA and comply with its decisions; clause 15.2 confirms the same bar on requiring a user to raise a complaint with another party to a shared electronic payments network." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.consumer-law-external-dispute-resolution-membership-from-2026-09-01", "id": "rule.consumer-law-external-dispute-resolution-membership-from-2026-09-01", "rail": "au-npp", "class": "Rule", "name": "Since 1 September 2026 a bank must belong to an authorised external dispute resolution scheme for scams", "statement": "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.", "rests_on": "law", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "au-npp:src.spf-regulated-sectors-designation-2026", "section": "provision 101(1) to (4)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.scams-prevention-framework-act-2025", "section": "section 58BZG(1) to (4)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.spf-regulated-entity", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.afca", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.spf-scam-complaint", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Competition and Consumer (Scams Prevention Framework, Regulated Sectors) Designation 2026, provision 101, and the Scams Prevention Framework Act 2025 section 58BZG, both read 2026-09-21.", "confidence": "high" }, "currency": { "effective_since": "2026-09-01", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the instrument itself. Provision 101(3) applies from 1 September 2026 and ends before 31 March 2027, when the rest of Part IVF applies as well. Which scheme is the authorised one was not established from the Designation, which does not name it.", "source_edition": "Scams Prevention Framework Act 2025 (No. 15, 2025) as made, read 2026-09-21, together with the Competition and Consumer (Scams Prevention Framework, Regulated Sectors) Designation 2026 (F2026L00627), read the same day. Part IVF of the Competition and Consumer Act 2010 was not read as a current compilation, so a later amendment to a cited section is not held [Unverified].", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.spf-regulated-sectors-designation-2026", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Section 101(1) to (4) confirms the Designation switches off all of Part IVF for covered banking services except Division 3 and section 58DB until before 1 September 2026, and that from 1 September 2026 until before 31 March 2027 it also switches on section 58BZG, the civil penalty provisions on membership of, cooperation with, and compliance with sector code obligations relating to an SPF EDR scheme." }, { "source": "au-npp:src.scams-prevention-framework-act-2025", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Section 58BZG(1) to (4) confirms the civil penalty provisions this Designation window switches on: providing a regulated service while not a member of an SPF EDR scheme for the sector, failing to give reasonable assistance to or cooperate with the scheme operator, and failing to comply with a related SPF code obligation." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.consumer-law-internal-dispute-resolution-and-apportionment-guidelines", "id": "rule.consumer-law-internal-dispute-resolution-and-apportionment-guidelines", "rail": "au-npp", "class": "Rule", "name": "A regulated entity must run internal dispute resolution and have regard to any apportionment guidelines", "statement": "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.", "rests_on": "law", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "au-npp:src.scams-prevention-framework-act-2025", "section": "sections 58BZB, 58BZC, 58BZD, 58BZE(1) and (1A) and 58BZF", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.spf-regulated-entity", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.spf-scam-complaint", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Scams Prevention Framework Act 2025 as made, at the sections named, read 2026-09-21. Whether any framework rules or sector code prescribing such guidelines have been registered was not established [Unverified].", "confidence": "medium" }, "currency": { "effective_since": "2027-03-31", "effective_to": null, "effective_note": "Effective since 2027-03-31: for covered banking services this provision is switched off by the Designation's transitional rule until before that date Drafted 2026-09-21 from the Act as made. If a framework rules instrument prescribing apportionment guidelines is registered, this record and the liability fact both change.", "source_edition": "Scams Prevention Framework Act 2025 (No. 15, 2025) as made, read 2026-09-21, together with the Competition and Consumer (Scams Prevention Framework, Regulated Sectors) Designation 2026 (F2026L00627), read the same day. Part IVF of the Competition and Consumer Act 2010 was not read as a current compilation, so a later amendment to a cited section is not held [Unverified].", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.scams-prevention-framework-act-2025", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Sections 58BZB, 58BZC and 58BZD confirm a regulated entity must have an accessible mechanism for reporting suspected scams and an accessible, transparent internal dispute resolution mechanism, and must publish information about both, each as a civil penalty provision. Section 58BZE confirms the entity must have regard to any SPF rules process and to any SPF rules guidelines for apportioning liability when handling such a complaint, and subsection 58BZE(1A) states in terms that those guidelines do not have to be consistent with sections 58FZD to 58FZK on proportionate liability for concurrent wrongdoers, which is the Act's own general damages rule." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.consumer-law-the-epayments-code-is-voluntary", "id": "rule.consumer-law-the-epayments-code-is-voluntary", "rail": "au-npp", "class": "Rule", "name": "The ePayments Code is voluntary and binds only the institutions that subscribe to it", "statement": "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.", "rests_on": "guidance", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "au-npp:src.epayments-code-2022", "section": "clause 25.1, and the Code as a whole", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "the definition of ePayments Code", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.subscriber", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.asic", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "ASIC's ePayments Code as published 2 June 2022, at the clauses named in the record's sourced_from link, read 2026-09-21. The rulebook's own definition of the Code was read the same day.", "confidence": "high" }, "currency": { "effective_since": "2022-06-02", "effective_to": null, "effective_note": "Drafted 2026-09-21 from ASIC's own current text of the ePayments Code. The Code is voluntary and binds subscribers only; which institutions subscribe was not established here.", "source_edition": "ePayments Code as published by ASIC on 2 June 2022, read 2026-09-21.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.epayments-code-2022", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Clause 25.1 confirms the mistaken internet payment chapter applies to subscribers that are ADIs other than providers of purchased payment facilities, and the Code as a whole is expressed throughout as obligations of subscribers rather than as legislation." }, { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "The NPP Regulations' own definition of ePayments Code confirms it as the electronic payments code administered by ASIC which regulates electronic payment facilities in Australia, referenced by the Regulations rather than incorporated as legislation." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.consumer-law-the-rest-of-part-ivf-reaches-banking-on-2027-03-31", "id": "rule.consumer-law-the-rest-of-part-ivf-reaches-banking-on-2027-03-31", "rail": "au-npp", "class": "Rule", "name": "The whole of the framework reaches banking from 31 March 2027", "statement": "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.", "rests_on": "law", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "au-npp:src.spf-regulated-sectors-designation-2026", "section": "provision 101(3) and (4)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.spf-regulated-entity", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.asic", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Competition and Consumer (Scams Prevention Framework, Regulated Sectors) Designation 2026, provision 101(4), read 2026-09-21.", "confidence": "high" }, "currency": { "effective_since": "2027-03-31", "effective_to": null, "effective_note": "Drafted 2026-09-21. This record states a rule that takes effect after the corpus snapshot, which is why it reads as a future dated provision rather than the rule in force today.", "source_edition": "Scams Prevention Framework Act 2025 (No. 15, 2025) as made, read 2026-09-21, together with the Competition and Consumer (Scams Prevention Framework, Regulated Sectors) Designation 2026 (F2026L00627), read the same day. Part IVF of the Competition and Consumer Act 2010 was not read as a current compilation, so a later amendment to a cited section is not held [Unverified].", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.spf-regulated-sectors-designation-2026", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Section 101(3) and (4) confirms the partial exception for covered banking services ends before 31 March 2027, after which the transitional carve-out in section 101 no longer applies and the whole of Part IVF, not only section 58BZG, governs covered banking services." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.consumer-law-the-six-scams-prevention-framework-principles", "id": "rule.consumer-law-the-six-scams-prevention-framework-principles", "rail": "au-npp", "class": "Rule", "name": "The Scams Prevention Framework puts six principles on a regulated entity, each backed by civil penalties", "statement": "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.", "rests_on": "law", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "au-npp:src.scams-prevention-framework-act-2025", "section": "Part IVF Division 2, Subdivisions B to G", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.spf-regulated-sectors-designation-2026", "section": "sections 11 and 12", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.spf-regulated-entity", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.asic", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Scams Prevention Framework Act 2025 as made and the Regulated Sectors Designation 2026, both read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "2026-05-29", "effective_to": null, "effective_note": "Effective since 2026-05-29: the Designation commenced the day after it was registered on 28 May 2026 Drafted 2026-09-21. The principles reach banking in stages: see the transitional rules in the Designation. The Act was read as made rather than as a current compilation [Unverified].", "source_edition": "Scams Prevention Framework Act 2025 (No. 15, 2025) as made, read 2026-09-21, together with the Competition and Consumer (Scams Prevention Framework, Regulated Sectors) Designation 2026 (F2026L00627), read the same day. Part IVF of the Competition and Consumer Act 2010 was not read as a current compilation, so a later amendment to a cited section is not held [Unverified].", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.scams-prevention-framework-act-2025", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Part IVF Division 2 Subdivisions B to G confirm the six SPF principles as governance, prevent, detect, report, disrupt and respond, each carried by civil penalty provisions." }, { "source": "au-npp:src.spf-regulated-sectors-designation-2026", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Sections 11 and 12 of the Designation confirm a covered banking service is a service an ADI provides in carrying on its banking business in Australia or a purchased payment facility an ADI provides, designated as a regulated sector, with ASIC designated as its SPF sector regulator." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.decision-points-the-payee-participant-accepts-or-rejects", "id": "rule.decision-points-the-payee-participant-accepts-or-rejects", "rail": "au-npp", "class": "Rule", "name": "The receiving institution decides, inside a timeout nobody outside the scheme can see", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 6.3(a)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payee-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.clearing-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:rule.hours-response-timeout-values-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 6.3(a) confirms the Payee Participant must respond to each Clearing Request within the configurable time out values NPPA prescribes, either accepting it or rejecting it with a valid and applicable reason code, and no figure for the timeout is given." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.decision-points-the-payer-acts-on-a-confirmation-of-payee-outcome", "id": "rule.decision-points-the-payer-acts-on-a-confirmation-of-payee-outcome", "rail": "au-npp", "class": "Rule", "name": "The payer decides what to do with a Confirmation of Payee outcome, and the service is compulsory for two roles", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 18.1(a), (b) and (f)", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.confirmed-data-holder", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-customer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.nppa", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not this Part as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified]. The outcomes a payer sees and the reason values behind them are in NPP Procedures Volume 12, which is participant material and was not consulted.", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "primary_not_public": true, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.decision-points-the-payer-customer-authorises-pauses-or-cancels-a-mandate", "id": "rule.decision-points-the-payer-customer-authorises-pauses-or-cancels-a-mandate", "rail": "au-npp", "class": "Rule", "name": "The payer decides on a PayTo agreement, and can pause, resume, amend or cancel it in their own banking", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 17.6(c)(iii), (v) and (vii)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.auspayplus-payto-faqs", "section": "managing PayTo agreements", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-customer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:rule.mandate-the-payer-customer-can-view-suspend-cancel-and-amend", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 17.6(c)(iii) confirms the Mandate Authorisation Request is delivered to the Payer Customer for authorisation, and Regulation 17.6(c)(vii) confirms the Payer Participant must provide a facility for the Payer Customer to view Mandates and instruct suspension, cancellation or permitted amendments, promptly given effect to." }, { "source": "au-npp:src.auspayplus-payto-faqs", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Confirms a payer may pause, resume or cancel a PayTo agreement in their own online banking, may resume an agreement they previously paused, and that pausing or cancelling does not change their contractual arrangement with the business." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.decision-points-the-payer-participant-may-seek-confirmation-of-a-migrated-mandate", "id": "rule.decision-points-the-payer-participant-may-seek-confirmation-of-a-migrated-mandate", "rail": "au-npp", "class": "Rule", "name": "With a migrated mandate the payer's institution may ask its customer, and must keep processing until it hears", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 17.4(d)(i) to (iv)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-customer", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "2021-06-30", "effective_to": null, "effective_note": "Effective since 2021-06-30: Regulation 17.4(d) carries that drafting date Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 17.4(d)(i) to (iv) confirm the Payer Participant could optionally satisfy itself a Migrated DDR Mandate matches the customer's existing arrangement and may seek the customer's confirmation, must keep a record if confirmed, must act promptly on an indication the customer did not authorise it or an instruction to suspend or cancel, and must otherwise keep processing pending any word from the customer." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.decision-points-the-payer-participant-screens-before-it-sends", "id": "rule.decision-points-the-payer-participant-screens-before-it-sends", "rail": "au-npp", "class": "Rule", "name": "The paying institution screens before it sends, and attests to its framework once a year", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 6.1(d)(i) to (vi), (e) and (f)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.sponsor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.nppa", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 6.1(d) confirms each NPP Participant acknowledges responsibility for its own compliance and for satisfying itself that each sponsored Identified Institution has a compliance framework, must maintain a Sanctions Compliance Framework and a KYC Due Diligence Framework and review each at least annually, and must give NPPA an annual attestation by a senior officer that each framework is in operation and being implemented and that Daily Customer Screening is being carried out; Regulation 6.1(e) confirms NPPA maintains a register of those attestations available to all NPP Participants." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.finality-a-cleared-payment-the-fss-rejects-is-void", "id": "rule.finality-a-cleared-payment-the-fss-rejects-is-void", "rail": "au-npp", "class": "Rule", "name": "A cleared payment the settlement service rejects is void, and the paying institution owes nothing for it", "statement": "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.", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 6.2(e), 6.2(f)(ii)(A) and 7.4(b)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payee-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.settlement-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.bsct", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulations 6.2(e) and 6.2(f)(ii)(A) confirm a Cleared NPP Payment the FSS rejects is deemed immediately void and the Payer Participant is not liable to discharge any obligation to the Payee Participant or the Payee in respect of it." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:state.cleared", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:state.voided-by-settlement-rejection", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.finality-cleared-means-the-payee-participant-accepted-it", "id": "rule.finality-cleared-means-the-payee-participant-accepted-it", "rail": "au-npp", "class": "Rule", "name": "Cleared means the receiving institution accepted it, and cleared is not settled", "statement": "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.", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 6.2(b) and 6.2(f)(i)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payee-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.bsct", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulations 6.2(b) and 6.2(f)(i) confirm a payment is cleared at the point the Payer Participant receives a Clearing Notification from the Payee Participant with an acceptance status, and that nothing in the Regulations or Procedures obliges the Payee Participant to apply a cleared payment to an account before settlement." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:state.cleared", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.finality-irrevocable-on-settlement-in-the-fss", "id": "rule.finality-irrevocable-on-settlement-in-the-fss", "rail": "au-npp", "class": "Rule", "name": "A cleared payment becomes irrevocable when the Fast Settlement Service settles it", "statement": "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.", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 6.2(d) and 7.4(a)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payee-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.bsct", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 6.2(d) confirms a Cleared NPP Payment is irrevocable when settled by the FSS, and that settlement is confirmed to both participants by a Settlement Notification indicating successful settlement." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:state.settled", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.finality-no-cancel-or-recall-once-the-message-is-in-the-gateway", "id": "rule.finality-no-cancel-or-recall-once-the-message-is-in-the-gateway", "rail": "au-npp", "class": "Rule", "name": "The paying institution cannot cancel or recall a payment once the message is in its own gateway", "statement": "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.", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 6.2(a)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.bsct", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.os-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.mandate-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.settlement-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:rule.recall-there-is-no-recall-and-no-cancellation-message", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 6.2(a) confirms the Payer Participant may not cancel or recall a Clearing Request once the message is input into its own gateway." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.recall-there-is-no-recall-and-no-cancellation-message", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:state.submitted-to-the-gateway", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.finality-rtgs-settlement-is-final-under-the-netting-act", "id": "rule.finality-rtgs-settlement-is-final-under-the-netting-act", "rail": "au-npp", "class": "Rule", "name": "Settlement through RITS is final and irrevocable as a matter of statute", "statement": "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.", "rests_on": "law", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "au-npp:src.rba-about-rits", "section": "Real-time Gross Settlement", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.rba-fss-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:rule.settlement-per-payment-rtgs-across-exchange-settlement-accounts", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The Reserve Bank of Australia's About RITS page, read 2026-09-21. The Payment Systems and Netting Act 1998 itself was not opened.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the page does not date the approval", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the Reserve Bank's own description of the system it owns and operates. The Act was not read and the date of approval is [Unverified].", "source_edition": "Reserve Bank of Australia, About RITS, live page read 2026-09-21.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.rba-about-rits", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "The RBA's About RITS page confirms RITS is an approved RTGS system under the Payment Systems and Netting Act 1998 and that RTGS transactions settled through RITS are final and irrevocable." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:state.settled", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.finality-the-payer-participant-alone-decides-to-replay-or-retry", "id": "rule.finality-the-payer-participant-alone-decides-to-replay-or-retry", "rail": "au-npp", "class": "Rule", "name": "After a settlement rejection the paying institution alone decides whether to replay or retry", "statement": "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.", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 6.2(f)(ii)(B), and the definitions of Replay and Retry", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.settlement-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:rule.messages-a-retry-and-a-replay-are-not-the-same-thing", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 6.2(f)(ii)(B) confirms the Payer Participant is solely responsible for deciding whether to Replay or Retry a payment the FSS has rejected, and the definitions of Replay and Retry confirm they are different acts, a resend under the same transaction identifier against a resend that marks itself in the 35th character of the transaction or return identifier." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:state.voided-by-settlement-rejection", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.hours-clearing-and-settlement-run-24-hours-every-day", "id": "rule.hours-clearing-and-settlement-run-24-hours-every-day", "rail": "au-npp", "class": "Rule", "name": "Clearing and settlement both run 24 hours a day, every day of the year", "statement": "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.", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 4.1(a)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.rba-about-rits", "section": "About RITS", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.nppa", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.rba-fss-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The Reserve Bank of Australia's About RITS page, read 2026-09-21, together with the NPP Regulations v21.0 of 24 September 2024 at the regulation named in the record's links.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 4.1(a) confirms the NPP Basic Infrastructure was established as a utility payments platform to facilitate near real time clearing and settlement of NPP Payments on a 24x7 basis." }, { "source": "au-npp:src.rba-about-rits", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "The RBA's About RITS page confirms the FSS was designed to settle individual transactions, including consumer and business payments, 24 hours a day and 7 days a week." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.hours-response-timeout-values-are-not-public", "id": "rule.hours-response-timeout-values-are-not-public", "rail": "au-npp", "class": "Rule", "name": "Every response timeout is a configurable value the operator prescribes, and no figure is public", "statement": "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.", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 6.3(a) and 7.2(a)", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payee-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.nppa", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified]. The values themselves are prescribed in the NPP Procedures, which are participant material and were not consulted.", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "primary_not_public": true, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.decision-points-the-payee-participant-accepts-or-rejects", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:state.rejected-at-clearing", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.hours-service-availability-targets-are-not-public", "id": "rule.hours-service-availability-targets-are-not-public", "rail": "au-npp", "class": "Rule", "name": "Service availability is a compliance requirement and the target is not published", "statement": "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.", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 3.8 as referred to in 17.1(h)(v) and 17.1(j)(v)(B), and Regulation 6.3(b)", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payee-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.nppa", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified]. The designated requirements and their targets sit outside the rulebook and were not consulted.", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "primary_not_public": true, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "au-npp:state.applied-to-the-payee-account", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.liability-a-deceived-payer-is-not-an-unauthorised-transaction", "id": "rule.liability-a-deceived-payer-is-not-an-unauthorised-transaction", "rail": "au-npp", "class": "Rule", "name": "A payment the customer made because they were deceived is not an unauthorised transaction", "statement": "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.", "rests_on": "guidance", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "au-npp:src.epayments-code-2022", "section": "clauses 9.2, 9.3 and the note to the definition of mistaken internet payment in clause 25.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.subscriber", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-customer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.unauthorised-transaction-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:rule.liability-australia-has-no-mandatory-scam-reimbursement-rule", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "ASIC's ePayments Code as published 2 June 2022, at the clauses named in the record's sourced_from link, read 2026-09-21.", "confidence": "high" }, "currency": { "effective_since": "2022-06-02", "effective_to": null, "effective_note": "Drafted 2026-09-21 from ASIC's own current text of the ePayments Code. The Code is voluntary and binds subscribers only; which institutions subscribe was not established here.", "source_edition": "ePayments Code as published by ASIC on 2 June 2022, read 2026-09-21.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.epayments-code-2022", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Clauses 9.2 and 9.3 confirm the unauthorised transactions chapter applies to unauthorised transactions and that an unauthorised transaction does not include one performed by the user or by anyone with the user's knowledge and consent, and the note to the mistaken internet payment definition in clause 25.2 confirms that definition is intended for typographical or selection errors and is not intended to cover a transfer made as a result of a scam." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.liability-a-registering-participant-indemnifies-a-misdirected-payment", "id": "rule.liability-a-registering-participant-indemnifies-a-misdirected-payment", "rail": "au-npp", "class": "Rule", "name": "A badly registered PayID is the registering institution's indemnity, not the payer's", "statement": "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.", "rests_on": "rule", "facet": "liability", "parameters": { "liability_holder": { "role": "au-npp:role.registering-participant", "condition": "the payment was misdirected because the registering institution did not accurately register or maintain the alias information for the account holder", "text": "The indemnity sits with the registering institution. Regulation 8.4(i) is named by the note to Regulation 6.5(b); the text of 8.4(i) itself was not located in the edition read [Unverified]." } }, "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "the note to Regulation 6.5(b), which points at Regulation 8.4(i), and Regulation 8.3(c)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.registering-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.misdirected-payment-return-request", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 8.4(i) was located in this edition and confirms the indemnity: the Registering Participant indemnifies a Full Participant, Clearing Participant, Connected Institution or Connected Overlay Service Provider against loss arising from reliance on Alias Information from an Addressing Lookup, limited to loss attributable to the Registering Participant's own breach of its Part 8 obligations and excluding fraud, which the note to Regulation 6.5(b) confirms applies to a Misdirected Payment caused by inaccurate alias registration; Regulation 8.3(c) confirms the Registering Participant's warranties on authorisation, account holder authority, verification and accuracy of the Alias Information it registers." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.liability-a-scam-victim-recovers-by-proving-a-contravention", "id": "rule.liability-a-scam-victim-recovers-by-proving-a-contravention", "rail": "au-npp", "class": "Rule", "name": "A scam victim recovers by proving a contravention caused the loss, within 6 years, apportioned", "statement": "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.", "rests_on": "law", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "au-npp:src.scams-prevention-framework-act-2025", "section": "sections 58FZC(1) to (4), 58FZD, 58FZF and 58FD", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.spf-regulated-entity", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-customer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.spf-scam-complaint", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Scams Prevention Framework Act 2025 (No. 15, 2025) as made, at the sections named, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-01", "effective_to": null, "effective_note": "Effective since 2026-09-01: for banking, the framework applies in stages under the Regulated Sectors Designation 2026 and the whole of Part IVF reaches covered banking services from 31 March 2027 Drafted 2026-09-21 from the Act as made rather than from a current compilation of Part IVF of the Competition and Consumer Act 2010, so a later amendment to a cited section is not held [Unverified].", "source_edition": "Scams Prevention Framework Act 2025 (No. 15, 2025) as made, read 2026-09-21, together with the Competition and Consumer (Scams Prevention Framework, Regulated Sectors) Designation 2026 (F2026L00627), read the same day. Part IVF of the Competition and Consumer Act 2010 was not read as a current compilation, so a later amendment to a cited section is not held [Unverified].", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.scams-prevention-framework-act-2025", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Section 58FZC confirms a victim who suffers loss by conduct done in contravention of a civil penalty provision of an SPF principle or SPF code may recover that loss by action, that a regulator may bring the claim with the victim's written consent, and that a claim may be made within 6 years of the cause of action accruing; section 58FZC(4) and section 58FZF confirm this is subject to proportionate liability among concurrent wrongdoers, apportioned by the court according to each defendant's responsibility; section 58FD confirms a court must prefer ordering compensation over a pecuniary penalty where a defendant cannot pay both." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.liability-australia-has-no-mandatory-scam-reimbursement-rule", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.liability-a-sponsor-takes-full-risk-on-the-users-it-sponsors", "id": "rule.liability-a-sponsor-takes-full-risk-on-the-users-it-sponsors", "rail": "au-npp", "class": "Rule", "name": "A sponsor takes full risk on the users it puts into the mandate service", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 17.5(d)(i) to (ix)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.sponsor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.mps-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.mandate-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 17.5(d) confirms a sponsoring participant is responsible for and takes full risk on approving and sponsoring MPS Users, covering creditworthiness assessment, capability and compliance checks, due diligence, oversight of use, action where a user stops qualifying, breaches law or becomes insolvent, and the indemnity for mandate claims arising from that user's use of the service." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.liability-australia-has-no-mandatory-scam-reimbursement-rule", "id": "rule.liability-australia-has-no-mandatory-scam-reimbursement-rule", "rail": "au-npp", "class": "Rule", "name": "Australia has no mandatory scam reimbursement rule", "statement": "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.", "rests_on": "law", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "au-npp:src.epayments-code-2022", "section": "clauses 9.2 and 9.3", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.scams-prevention-framework-act-2025", "section": "Part IVF Division 2, the six principles, and Subdivision G, section 58FZC", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.spf-regulated-entity", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-customer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:rule.liability-a-scam-victim-recovers-by-proving-a-contravention", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:rule.app-reimbursement-requirement", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "ASIC's ePayments Code of 2 June 2022 at clauses 9.2 and 9.3, and the Scams Prevention Framework Act 2025 as made, read together on 2026-09-21. The claim is that no reimbursement duty was found in either instrument, which is a statement about what two named documents do not contain rather than about Australian law as a whole [Inference].", "confidence": "medium" }, "currency": { "effective_since": "2025-02-20", "effective_to": null, "effective_note": "Effective since 2025-02-20: the framework Act was assented on that date and creates no reimbursement duty; the ePayments Code exclusion has stood since 2 June 2022 Drafted 2026-09-21 from the two instruments named. The Scams Prevention Framework rules and the sector codes may prescribe guidelines for apportioning liability in internal dispute resolution, and whether any such instrument has been registered was not established, so this record would need re-reading if one appears [Unverified].", "source_edition": "Scams Prevention Framework Act 2025 (No. 15, 2025) as made, read 2026-09-21, together with the Competition and Consumer (Scams Prevention Framework, Regulated Sectors) Designation 2026 (F2026L00627), read the same day. Part IVF of the Competition and Consumer Act 2010 was not read as a current compilation, so a later amendment to a cited section is not held [Unverified]. ASIC's ePayments Code as published 2 June 2022 was read the same day.", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.liability-a-deceived-payer-is-not-an-unauthorised-transaction", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.liability-the-holder-is-liable-where-the-subscriber-proves-contribution", "id": "rule.liability-the-holder-is-liable-where-the-subscriber-proves-contribution", "rail": "au-npp", "class": "Rule", "name": "A customer carries the loss only where the institution proves they contributed, and never above their own limits", "statement": "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.", "rests_on": "guidance", "facet": "liability", "parameters": { "liability_holder": { "role": "au-npp:role.payer-customer", "condition": "the subscriber proves on the balance of probability that the user contributed through fraud, a breach of the passcode security requirements, or an unreasonable delay in reporting", "text": "The customer carries the actual losses in the relevant period, capped by their own daily and periodic limits and by what was available on the facility." } }, "relations": [ { "type": "sourced_from", "to": "au-npp:src.epayments-code-2022", "section": "clauses 11.2, 11.3, 11.5, 11.6 and 11.8", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.subscriber", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-customer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.unauthorised-transaction-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "ASIC's ePayments Code as published 2 June 2022, at the clauses named in the record's sourced_from link, read 2026-09-21.", "confidence": "high" }, "currency": { "effective_since": "2022-06-02", "effective_to": null, "effective_note": "Drafted 2026-09-21 from ASIC's own current text of the ePayments Code. The Code is voluntary and binds subscribers only; which institutions subscribe was not established here.", "source_edition": "ePayments Code as published by ASIC on 2 June 2022, read 2026-09-21.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.epayments-code-2022", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Clauses 11.2, 11.3 and 11.5 confirm the holder is liable for actual losses in the relevant period where the subscriber proves on the balance of probability the user contributed by fraud, a passcode security breach, or unreasonable delay in reporting, subject to the caps in clause 11.2(b); clause 11.6 confirms the effect of any charges for reporting or replacement must be considered; clause 11.8 confirms use of the correct device or passcode is significant but not by itself proof of contribution." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.liability-the-holder-is-not-liable-where-an-identifier-alone-can-pay", "id": "rule.liability-the-holder-is-not-liable-where-an-identifier-alone-can-pay", "rail": "au-npp", "class": "Rule", "name": "A customer is not liable where a payment could be made with an identifier and nothing else", "statement": "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.", "rests_on": "guidance", "facet": "liability", "parameters": { "liability_holder": { "role": "au-npp:role.subscriber", "condition": "the transaction could be made using an identifier alone, or falls into any of the causes listed in clause 10.1, or the user clearly did not contribute", "text": "The institution carries the loss. Being able to pay from an account with nothing but an identifier puts the loss on the institution that allowed it." } }, "relations": [ { "type": "sourced_from", "to": "au-npp:src.epayments-code-2022", "section": "clauses 10.1, 10.2 and 10.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.subscriber", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-customer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.unauthorised-transaction-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "ASIC's ePayments Code as published 2 June 2022, at the clauses named in the record's sourced_from link, read 2026-09-21.", "confidence": "high" }, "currency": { "effective_since": "2022-06-02", "effective_to": null, "effective_note": "Drafted 2026-09-21 from ASIC's own current text of the ePayments Code. The Code is voluntary and binds subscribers only; which institutions subscribe was not established here.", "source_edition": "ePayments Code as published by ASIC on 2 June 2022, read 2026-09-21.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.epayments-code-2022", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Clauses 10.1 to 10.3 confirm a holder is not liable for loss from an unauthorised transaction caused by subscriber or network fraud or negligence, a forged, faulty, expired or cancelled device or passcode, a transaction before the device or passcode was received, a double debit, or a transaction after loss was reported, and is not liable where the transaction could be made using an identifier alone without a passcode or device, with liability only for unreasonable delay where a device but no passcode was needed, and no liability where the user clearly did not contribute." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.liability-the-initiating-participant-indemnifies-against-mandate-claims", "id": "rule.liability-the-initiating-participant-indemnifies-against-mandate-claims", "rail": "au-npp", "class": "Rule", "name": "The side that sent the mandate payment request indemnifies everybody else against substantiated claims", "statement": "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.", "rests_on": "rule", "facet": "liability", "parameters": { "liability_holder": { "role": "au-npp:role.initiating-participant", "condition": "a mandate claim against the payment it initiated is substantiated", "text": "The initiating side pays, reduced by anything the paying institution has already recovered from the receiving institution for the same claim." } }, "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 17.10(a) and (b)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.initiating-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.nppa", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.mandate-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 17.10(a) confirms a participant that approves MPS Users and initiates requests on their behalf, and a Connected Institution that initiates requests as or for a Payment Initiator, each indemnifies NPPA and every other participant against claims, liabilities, expenses and direct losses in respect of Mandate Claims, and Regulation 17.10(b) confirms that liability is reduced by any sum the indemnified party recovers from another participant for the same claim." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.liability-the-residual-cap-is-150-dollars", "id": "rule.liability-the-residual-cap-is-150-dollars", "rail": "au-npp", "class": "Rule", "name": "Where nothing else applies and a passcode was needed, the customer's share is capped at 150 dollars", "statement": "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.", "rests_on": "guidance", "facet": "liability", "parameters": { "limit": { "amount": 150, "currency": "AUD", "per": "entry", "kind": "cap", "text": "150 dollars, or a lower figure the institution sets, and only where a passcode was required and no other liability provision applies. The holder's liability is the least of that figure, the available balance, and the actual loss at the time of reporting." } }, "relations": [ { "type": "sourced_from", "to": "au-npp:src.epayments-code-2022", "section": "clauses 11.7 and 11.9", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.subscriber", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-customer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.unauthorised-transaction-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "ASIC's ePayments Code as published 2 June 2022, at the clauses named in the record's sourced_from link, read 2026-09-21.", "confidence": "high" }, "currency": { "effective_since": "2022-06-02", "effective_to": null, "effective_note": "Drafted 2026-09-21 from ASIC's own current text of the ePayments Code. The Code is voluntary and binds subscribers only; which institutions subscribe was not established here.", "source_edition": "ePayments Code as published by ASIC on 2 June 2022, read 2026-09-21.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.epayments-code-2022", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Clause 11.7 confirms that where a passcode was required and clauses 11.2 to 11.6 do not apply, the holder is liable for the least of 150 dollars or a lower figure the subscriber sets, the balance available on the facility, and the actual loss at the time of reporting excluding amounts above a relevant limit; clause 11.9 confirms the subscriber or an external dispute resolution body may further reduce liability where no reasonable transaction limit was applied." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.limits-a-zero-value-payment-is-forbidden", "id": "rule.limits-a-zero-value-payment-is-forbidden", "rail": "au-npp", "class": "Rule", "name": "A zero value payment may not be sent and must be rejected", "statement": "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.", "rests_on": "rule", "facet": "limits", "parameters": { "limit": { "amount": 0, "currency": "AUD", "per": "entry", "kind": "floor", "text": "A zero value is forbidden. The rulebook gives no positive minimum, so the floor is the exclusion of zero rather than a smallest permitted amount." } }, "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 6.1(c)(i) and (ii)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payee-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.bsct", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.npp-payment-return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.clearing-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:rule.return-a-zero-value-return-is-forbidden", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, 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 marks a later amendment to this provision. Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 6.1(c) confirms a Payer Participant must not submit a BSCT Clearing Request with a zero value amount and a Payee Participant is obliged to reject one that arrives, and must not submit an NPP Payment Return with a zero value." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.return-a-zero-value-return-is-forbidden", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM01", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.limits-nppa-may-direct-value-limits-for-capacity", "id": "rule.limits-nppa-may-direct-value-limits-for-capacity", "rail": "au-npp", "class": "Rule", "name": "The operator may direct value limits and volume controls to keep the platform orderly", "statement": "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.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 14.4(a) and (b)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.nppa", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.full-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.clearing-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.connected-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, 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 marks a later amendment to this provision. Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 14.4(a) and (b) confirms NPPA may direct a Full Participant, Clearing Participant or Connected Institution to impose value limits and volume controls on NPP Payments, Non-Value Messages and Addressing Service activity to ensure the orderly operation of the infrastructure, and that the institution must comply promptly and maintain the controls until directed otherwise." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.limits-participants-set-their-own-customer-limits", "id": "rule.limits-participants-set-their-own-customer-limits", "rail": "au-npp", "class": "Rule", "name": "Any limit a customer meets is their own institution's, not the scheme's", "statement": "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.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Appendix C, clause C.3 and its note to participants", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.osko-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, 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 marks a later amendment to this provision. Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Appendix C clause C.3 of the sample Osko customer terms confirms transaction limits are left as a blank for the Osko Participant to insert, with a note that different limits may be specified for different payment types." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.limits-the-scheme-sets-no-maximum-value", "id": "rule.limits-the-scheme-sets-no-maximum-value", "rail": "au-npp", "class": "Rule", "name": "The scheme sets no maximum payment value at all", "statement": "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.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 6.1(b)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.bsct", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, 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 marks a later amendment to this provision. Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 6.1(b) sets what an NPP Payment must be, denominated in AUD, between Australian domiciled accounts, correctly formatted and carrying a transaction identifier, and states no ceiling on value." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.mandate-a-mandate-is-a-record-in-the-scheme-operators-database", "id": "rule.mandate-a-mandate-is-a-record-in-the-scheme-operators-database", "rail": "au-npp", "class": "Rule", "name": "A PayTo mandate is a record in a database the scheme operator runs, not a document a party keeps", "statement": "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.", "rests_on": "rule", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 17.1(a) and (b), and Regulation 17.1(g)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.nppa", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.mps-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-customer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.mandate-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 17.1(a) and (b) confirm the MMS is a centralised, secure, access controlled database of Mandates that NPPA established and operates, and that a Mandate is a record of payment authorisation given by a Payer Customer in favour of an MPS User or Payment Initiator, identified by a unique Mandate ID the MMS generates, giving the right to send Mandate Payment Initiation Requests within its terms; Regulation 17.1(b) also confirms the MMS may optionally hold Debtor Payment Arrangement records defined in the Procedures." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:mandate.authorised-payment-mandate", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:mandate.debtor-payment-arrangement", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:state.mandate-awaiting-authorisation", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:MD01", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.mandate-a-mandate-may-be-ported-to-another-participant", "id": "rule.mandate-a-mandate-may-be-ported-to-another-participant", "rail": "au-npp", "class": "Rule", "name": "A mandate may be moved to another institution without the authorisation changing", "statement": "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.", "rests_on": "rule", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 17.6(c)(vi), 17.5(f) and 17.7(b)(iv), and the Part 17 drafting note on porting", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payment-initiator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-customer", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "2023-05-05", "effective_to": null, "effective_note": "Effective since 2023-05-05: the Part 17 drafting note says every porting provision takes effect on that date Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 17.6(c)(vi) confirms the Payer Participant must facilitate porting of a Mandate at the Payer Customer's request, Regulation 17.5(f) confirms a Mandate established for a Payment Initiator may be moved to another participant or connected institution on the initiator's instruction, and Regulation 17.7(b)(iv) confirms an institution's right to access a Mandate record is subject to the parties' right to port it away." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:mandate.authorised-payment-mandate", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.mandate-a-migrated-mandate-claim-is-deemed-substantiated", "id": "rule.mandate-a-migrated-mandate-claim-is-deemed-substantiated", "rail": "au-npp", "class": "Rule", "name": "A claim about a migrated mandate is deemed substantiated unless the sponsor produces the evidence", "statement": "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.", "rests_on": "rule", "parameters": { "liability_holder": { "role": "au-npp:role.sponsor", "condition": "the sponsoring participant cannot produce written evidence of the original direct debit authorisation and that the payment was within the migrated mandate's terms", "text": "The claim is deemed substantiated and the sponsoring side carries it. Producing the evidence is what defeats the claim." } }, "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 17.10(c)(ii) and 17.10(e)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.sponsor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.mandate-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "2022-06-14", "effective_to": null, "effective_note": "Effective since 2022-06-14: Regulation 17.10(c) carries that drafting date Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 17.10(e) confirms a Mandate Claim relating to a Migrated DDR Mandate is deemed substantiated unless the sponsoring participant produces written evidence of the Payer Customer's authorisation of the original direct debit request and that the payment was authorised by the Migrated DDR Mandate's terms." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:mandate.migrated-ddr-mandate", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.mandate-a-migrated-mandate-is-created-without-a-consent-step", "id": "rule.mandate-a-migrated-mandate-is-created-without-a-consent-step", "rail": "au-npp", "class": "Rule", "name": "A migrated direct debit mandate is created unilaterally and is active the moment it exists", "statement": "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.", "rests_on": "rule", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 17.4(a), (b) and (d), and 17.6(c)(viii)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.sponsor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.mps-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.mandate-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 17.4(a), (b) and (d) confirm a Migrated DDR Mandate is created unilaterally by the MPS User and its sponsoring participant from an existing BECS direct debit arrangement, is deemed Active in the MMS immediately on creation with the Debit User deemed approved as an MPS User by the same act, and Regulation 17.6(c)(viii) confirms the obligations to deliver an authorisation request and facilitate porting under 17.6(c)(iii) and (vi) do not apply to Migrated DDR Mandates." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:mandate.migrated-ddr-mandate", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:state.mandate-active", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.mandate-a-request-may-not-be-sent-unless-the-mandate-is-active", "id": "rule.mandate-a-request-may-not-be-sent-unless-the-mandate-is-active", "rail": "au-npp", "class": "Rule", "name": "No payment request may be sent unless the mandate is active", "statement": "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.", "rests_on": "rule", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 17.8(a), (b) and (c), and 17.10(c)(i)(B)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.initiating-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.mandate-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.mandate-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulations 17.8(a) to (c) confirm an Initiating Participant must not send a Mandate Payment Initiation Request unless the associated Mandate is Active and is responsible for each request being properly constructed and consistent with the Mandate's terms, and Regulation 17.10(c)(i)(B) confirms a request sent while the Mandate is suspended or cancelled is treated as not authorised." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:mandate.authorised-payment-mandate", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:mandate.migrated-ddr-mandate", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:state.mandate-active", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:state.mandate-awaiting-authorisation", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:state.mandate-cancelled", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:state.mandate-declined", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:state.mandate-suspended", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:NAUT", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.mandate-an-amount-or-frequency-change-comes-from-the-business", "id": "rule.mandate-an-amount-or-frequency-change-comes-from-the-business", "rail": "au-npp", "class": "Rule", "name": "A change to the amount or the frequency has to come from the business as a fresh agreement", "statement": "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.", "rests_on": "guidance", "relations": [ { "type": "sourced_from", "to": "au-npp:src.auspayplus-payto-faqs", "section": "can I change, pause, resume or cancel my PayTo agreement", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 17.6(d), on a maintenance function being permitted by the mandate's terms", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.mps-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-customer", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Australian Payments Plus's PayTo FAQs, read 2026-09-21, together with Regulation 17.6(d) of the NPP Regulations v21.0, read the same day. The FAQs are the operator's parent describing the service to customers rather than the rulebook, so this is the weaker of the two sources on the point.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the FAQ page is undated", "effective_to": null, "effective_note": "Drafted 2026-09-21 from a live page. What counts as a permitted amendment is defined in the NPP Procedures Volume 6, which is participant material and was not consulted, so the boundary between what a payer may change and what the business must resend is not held [Unverified].", "source_edition": "Australian Payments Plus PayTo FAQs, live page read 2026-09-21, and NPP Regulations v21.0 of 24 September 2024.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.auspayplus-payto-faqs", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Confirms that for a change to a PayTo agreement's payment amount or frequency, the business or organisation must make the change and send the payer an updated agreement to authorise, rather than the payer changing it themselves." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:mandate.authorised-payment-mandate", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:state.mandate-active", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.mandate-an-authorised-mandate-claim-is-deemed-substantiated-by-the-record", "id": "rule.mandate-an-authorised-mandate-claim-is-deemed-substantiated-by-the-record", "rail": "au-npp", "class": "Rule", "name": "A claim about an ordinary mandate is tested against the record, or against evidence the initiator must produce", "statement": "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.", "rests_on": "rule", "parameters": { "liability_holder": { "role": "au-npp:role.initiating-participant", "condition": "the payment fell outside the mandate's amount, frequency or beneficiary as the record states them, or the initiating side cannot produce evidence that the payer authorised the particular payment", "text": "The initiating side carries a substantiated claim under the Part 17 indemnity." } }, "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 17.10(f)(i) and (ii), and Regulation 17.10(c)(i)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.initiating-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.mandate-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:rule.mandate-the-record-is-evidence-of-quantum-frequency-and-beneficiary", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "2022-06-14", "effective_to": null, "effective_note": "Effective since 2022-06-14: Regulation 17.10(c) carries that drafting date Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 17.10(f) confirms that for an Authorised Payment Mandate, a claim that a payment fell outside the Mandate's amount, frequency or beneficiary is deemed substantiated by reference to the Mandate record in the MMS, and a claim that the Payer Customer did not authorise the particular payment is deemed substantiated unless the Indemnifying Party produces evidence that they did, with Part 12 dispute resolution available if the parties disagree on that evidence; Regulation 17.10(c)(i) confirms what not authorised includes." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:mandate.authorised-payment-mandate", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.mandate-authorisation-is-delivered-in-near-real-time", "id": "rule.mandate-authorisation-is-delivered-in-near-real-time", "rail": "au-npp", "class": "Rule", "name": "The payer's institution must deliver the authorisation request to the payer in near real time", "statement": "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.", "rests_on": "rule", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 17.6(c)(i) to (v), and the definition of Active", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-customer", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "2020-12-02", "effective_to": null, "effective_note": "Effective since 2020-12-02: the definition of Active carries that drafting date Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 17.6(c)(i) to (v) confirm the Payer Participant must receive Mandate Authorisation Requests, associate each with a Payer Customer by account number, deliver it to the customer in near real time for authorisation to the Mandate Authorisation Standards, procure any consents Privacy Law requires, and record a Mandate Authorisation Confirmation promptly after the customer authorises or rejects it; the definition of Active confirms the Mandate becomes Active only once that confirmation is recorded." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:mandate.authorised-payment-mandate", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:state.mandate-active", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:state.mandate-awaiting-authorisation", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:state.mandate-declined", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.mandate-data-is-confidential-to-the-parties", "id": "rule.mandate-data-is-confidential-to-the-parties", "rail": "au-npp", "class": "Rule", "name": "A mandate record is confidential to its parties and may be looked up only by them", "statement": "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.", "rests_on": "rule", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 17.2(e) and 17.7(a) and (b)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.initiating-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.nppa", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 17.2(e) confirms Mandate record information must be treated as confidential to the parties and not disclosed except as law requires, with institutions required to have systems to prevent and detect unauthorised disclosure and to notify NPPA promptly when it occurs, and Regulation 17.7(a) and (b) confirm Mandate Lookup rights are restricted to the parties to the Mandate and to the specific purposes the Regulation lists." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:mandate.authorised-payment-mandate", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:mandate.migrated-ddr-mandate", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.mandate-five-days-before-a-migrated-mandate-may-be-used", "id": "rule.mandate-five-days-before-a-migrated-mandate-may-be-used", "rail": "au-npp", "class": "Rule", "name": "A migrated mandate may not be used for a payment request until 5 days after it was created", "statement": "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.", "rests_on": "rule", "parameters": { "time_window": { "count": 5, "unit": "calendar_day", "from": "processing_date", "actor": "au-npp:role.initiating-participant", "text": "5 days from the time and date the migrated mandate record was created, before it may be used for a payment request. The rulebook says five days without saying calendar or business days, and calendar days is Orca's reading [Inference]." } }, "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 17.4(e)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.initiating-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.mandate-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "2021-12-07", "effective_to": null, "effective_note": "Effective since 2021-12-07: Regulation 17.4(e) carries that drafting date Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 17.4(e) confirms a Migrated DDR Mandate may not be used to issue a Mandate Payment Initiation Request earlier than five days after the time and date of its creation, and that the record must carry the MPS User's BECS Debit User ID so the Payer Participant can check the Payer Customer's account status and transaction history." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:mandate.migrated-ddr-mandate", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.mandate-fourteen-days-notice-before-a-migrated-mandate-is-created", "id": "rule.mandate-fourteen-days-notice-before-a-migrated-mandate-is-created", "rail": "au-npp", "class": "Rule", "name": "A migrated mandate needs written notice to the payer first, at least 14 days ahead", "statement": "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.", "rests_on": "rule", "parameters": { "time_window": { "count": 14, "unit": "calendar_day", "from": "receipt", "actor": "au-npp:role.mps-user", "text": "At least 14 days before the migrated mandate record is created, or whatever longer notice the direct debit service agreement requires. The rulebook says fourteen days; it does not say whether they are calendar or business days, and calendar days is Orca's reading [Inference]." } }, "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 17.4(c)(i) to (iii)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.auspayplus-payto-faqs", "section": "what should I do if my direct debit is moving to PayTo, and do I have to agree", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.mps-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.sponsor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-customer", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21. Australian Payments Plus's PayTo FAQs, read the same day, give the payer facing version: 14 days advance notice and a right to opt out during it. The right to opt out is the parent's description and is not a provision Orca located in the rulebook [Unverified].", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 17.4(c)(i) confirms the MPS User must have notified each payer in writing that future debits will generally move to the platform, giving the notice its direct debit service agreement requires or at least fourteen days before the Migrated DDR Mandate record is created; Regulation 17.4(c)(ii) confirms the MPS User must hold and be able to produce evidence of the original direct debit authorisation and that notice; Regulation 17.4(c)(iii) confirms direct debit processing of the arrangement must cease from the migration date except during a genuine NPP outage." }, { "source": "au-npp:src.auspayplus-payto-faqs", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Confirms a payer receives 14 days advance notice from the business of its move to PayTo, that the payer does not need to do anything for the existing authorisation to carry forward, and that the payer may opt out during the notice period and remain on the direct debit system." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:mandate.migrated-ddr-mandate", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.mandate-indemnity-settlement-timeframes-are-not-public", "id": "rule.mandate-indemnity-settlement-timeframes-are-not-public", "rail": "au-npp", "class": "Rule", "name": "When a substantiated mandate claim has to be paid is in the procedures and is not public", "statement": "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.", "rests_on": "rule", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 17.10(g) and (h)", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.initiating-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.mandate-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified]. The settlement timeframes sit in NPP Procedures Volume 6, which is participant material and was not consulted.", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "primary_not_public": true, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.mandate-participation-is-mandatory-for-a-payer-participant", "id": "rule.mandate-participation-is-mandatory-for-a-payer-participant", "rail": "au-npp", "class": "Rule", "name": "Offering PayTo is optional for a creditor's bank and compulsory for the payer's bank", "statement": "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.", "rests_on": "rule", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 17.1(f)(i) to (iv) and Regulation 17.1(n)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.connected-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.overlay-service-provider", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "2021-12-07", "effective_to": null, "effective_note": "Effective since 2021-12-07: Regulation 17.1(n) carries that drafting date Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 17.1(f) confirms participation in the MPS is optional for participants providing services to MPS Users, optional for Connected Institutions and Overlay Service Providers, and mandatory for every NPP Participant and sponsored Identified Institution in its capacity as a Payer Participant and account servicer, and Regulation 17.1(n) confirms Payer Participants must provide MPS services for every eligible account type." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:mandate.authorised-payment-mandate", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.mandate-the-payer-customer-can-view-suspend-cancel-and-amend", "id": "rule.mandate-the-payer-customer-can-view-suspend-cancel-and-amend", "rail": "au-npp", "class": "Rule", "name": "The payer's institution must give the payer a way to view, suspend, cancel and amend their mandates", "statement": "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.", "rests_on": "rule", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 17.6(c)(vii) and 17.6(d)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.auspayplus-payto-faqs", "section": "can I change, pause, resume or cancel my PayTo agreement", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-customer", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21. Australian Payments Plus's PayTo FAQs were read the same day for the customer facing wording, including that a payer may resume an agreement they had paused, which the rulebook itself does not name as an operation.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 17.6(c)(vii) confirms the Payer Participant must provide a facility for the Payer Customer to view their Mandates and to instruct suspension, cancellation or permitted amendments, promptly given effect to, and Regulation 17.6(d) confirms whoever performs a Mandate Maintenance function is responsible for ensuring the particular Mandate's terms permit it." }, { "source": "au-npp:src.auspayplus-payto-faqs", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Confirms a payer may pause, resume or cancel a PayTo agreement in their own online banking, and that doing so does not change their contractual arrangement with the business." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:mandate.authorised-payment-mandate", "type": "revoked_via", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:mandate.migrated-ddr-mandate", "type": "revoked_via", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.decision-points-the-payer-customer-authorises-pauses-or-cancels-a-mandate", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:state.mandate-cancelled", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:state.mandate-suspended", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.mandate-the-payer-participant-keeps-processing-pending-word", "id": "rule.mandate-the-payer-participant-keeps-processing-pending-word", "rail": "au-npp", "class": "Rule", "name": "Until the payer says something, their institution must keep processing a migrated mandate", "statement": "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.", "rests_on": "rule", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 17.4(d)(i) to (iv)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-customer", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "2021-06-30", "effective_to": null, "effective_note": "Effective since 2021-06-30: Regulation 17.4(d) carries that drafting date Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 17.4(d) confirms the Payer Participant could optionally satisfy itself a Migrated DDR Mandate matches the customer's existing arrangement and may seek confirmation, must keep a record if confirmed, must act promptly if the customer says authorisation was not given or instructs suspension or cancellation, and must otherwise continue processing Mandate Payment Initiation Requests pending any word from the customer." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:mandate.migrated-ddr-mandate", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.mandate-the-record-is-evidence-of-quantum-frequency-and-beneficiary", "id": "rule.mandate-the-record-is-evidence-of-quantum-frequency-and-beneficiary", "rail": "au-npp", "class": "Rule", "name": "The mandate record is the evidence of the amount, the frequency and the beneficiary", "statement": "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.", "rests_on": "rule", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 17.10(d)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.initiating-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.mandate-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 17.10(d) confirms the Mandate record is evidence of the quantum, frequency and, if recorded, the beneficiary of the NPP Payments the Payer Customer authorised." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:mandate.authorised-payment-mandate", "type": "evidenced_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:mandate.migrated-ddr-mandate", "type": "evidenced_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-an-authorised-mandate-claim-is-deemed-substantiated-by-the-record", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.messages-a-rejected-clearing-request-carries-a-reason-code", "id": "rule.messages-a-rejected-clearing-request-carries-a-reason-code", "rail": "au-npp", "class": "Rule", "name": "A receiving institution that rejects a clearing request must put a valid and applicable reason code in the message", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 6.3(a)(i) and (ii)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payee-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.clearing-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 6.3(a) confirms a Payee Participant must answer every Clearing Request inside the configured timeout, accepting or rejecting it, and on rejection must include a valid and applicable Reason Code in the message, with no value listed in the Regulations themselves." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:state.rejected-at-clearing", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.messages-a-rejected-mandate-payment-request-carries-a-reason-code", "id": "rule.messages-a-rejected-mandate-payment-request-carries-a-reason-code", "rail": "au-npp", "class": "Rule", "name": "A rejected mandate payment initiation request must also carry a valid and applicable reason code", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 17.8(b)(i) and (ii)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.mandate-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 17.8(b) confirms a Payer Participant must respond to each Mandate Payment Initiation Request within the timeframes the Procedures prescribe by initiating a Mandate Payment Status Report indicating receipt and acceptance or rejection, providing a valid and applicable Reason Code if rejected, and, if accepted and funds are available, by then sending a Clearing Request for the amount claimed, with no reason code value listed in the Regulations themselves." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.messages-a-retry-and-a-replay-are-not-the-same-thing", "id": "rule.messages-a-retry-and-a-replay-are-not-the-same-thing", "rail": "au-npp", "class": "Rule", "name": "A replay and a retry are different messages, and a duplicate is a third thing again", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "the definitions of Replay, Retry and Duplicate Payment, and Regulations 6.4(a) and (b)", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payee-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.finality-the-payer-participant-alone-decides-to-replay-or-retry", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "id": "rule.messages-an-institution-may-offer-alternative-codes", "rail": "au-npp", "class": "Rule", "name": "An institution may offer alternative status and reason codes, and the authority says so under each list", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-payment-initiation-messages-v4", "section": "the notes under Appendix E and Appendix F", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.auspayplus", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.payment-initiation-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Payment Initiation Messages, technical guidance v4.0 of 20 November 2025, published by Australian Payments Plus and NPP Australia, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-22", "effective_to": null, "effective_note": "Effective since 2019-11-22: the guidance's own document control records version 1.0 on that date, and version 4.0 on 20 November 2025 Drafted 2026-09-21 from the guidance itself.", "source_edition": "NPP Payment Initiation Messages v4.0, dated 20 November 2025, uploaded March 2026, read 2026-09-21.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-payment-initiation-messages-v4", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "The notes under Appendix E and Appendix F confirm an NPP FI may offer alternative status codes and alternative reason codes, with further guidance on usage coming from that institution." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.messages-four-status-code-values-on-the-initiation-leg", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC05", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC06", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC07", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC13", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC14", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC15", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AG01", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AG03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AGNT", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM01", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM06", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM09", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM12", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM19", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM21", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:BE06", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:BE08", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:BE22", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:CH20", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:CH21", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:CURR", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:DT02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:DT04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:FF10", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:MD01", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:NARR", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:NAUT", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:TD03", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.messages-four-status-code-values-on-the-initiation-leg", "id": "rule.messages-four-status-code-values-on-the-initiation-leg", "rail": "au-npp", "class": "Rule", "name": "The authority publishes four status code values for the payment initiation leg", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-payment-initiation-messages-v4", "section": "Appendix E and its note", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.payment-initiation-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Payment Initiation Messages, technical guidance v4.0 of 20 November 2025, published by Australian Payments Plus and NPP Australia, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-22", "effective_to": null, "effective_note": "Effective since 2019-11-22: the guidance's own document control records version 1.0 on that date, and version 4.0 on 20 November 2025 Drafted 2026-09-21 from the guidance itself. Orca states what each value signals in its own words and does not reproduce the appendix.", "source_edition": "NPP Payment Initiation Messages v4.0, dated 20 November 2025, uploaded March 2026, read 2026-09-21.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-payment-initiation-messages-v4", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Appendix E confirms four status codes, ACTC for initial file validation completed with transactional validation not started, ACSC for all transactions in a file processed or a specific transaction settled and completed, RJCT for initial file validation failed with transactional validation not done, or a specific transaction rejected, and PART for partial processing of a bulk file across multiple portions, with the same alternative-codes note applying to them." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.messages-iso-20022-from-launch", "id": "rule.messages-iso-20022-from-launch", "rail": "au-npp", "class": "Rule", "name": "The platform has used ISO 20022 natively since launch", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "the definitions of Clearing Request, Clearing Notification, Settlement Request, Settlement Notification, NPP Payment Return and Request for Payment Return, and Regulation 17.1(c)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.npp-payment-initiation-messages-v4", "section": "Background", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.nppa", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.bsct", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.mandate-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21. NPP Payment Initiation Messages, technical guidance v4.0 of 20 November 2025, published by Australian Payments Plus and NPP Australia, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "The definitions of Clearing Request (pacs.008), Clearing Notification (pacs.002), Settlement Request (pacs.009), Settlement Notification (pacs.002), NPP Payment Return (pacs.004) and Request for Payment Return (camt.056) confirm each as an ISO 20022 NPP Message, and Regulation 17.1(c) confirms the Creditor Payment Initiation Request (pain.013) and Payment Initiation Request (pain.001) as the Mandate Payment Initiation Request message types." }, { "source": "au-npp:src.npp-payment-initiation-messages-v4", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "The Background section confirms the NPP uses ISO 20022 as its message standard, that an outgoing NPP payment is a pacs.008 Clearing Request settled in the RBA's Fast Settlement Service, and that corporate and government customers may submit payment instructions as pain.001 messages answered by pain.002 status report messages." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:state.submitted-to-the-gateway", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "id": "rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "rail": "au-npp", "class": "Rule", "name": "No public document says how long an institution has to answer a customer's payment instruction", "statement": "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.", "rests_on": "practice", "facet": "messages", "relations": [ { "type": "part_of", "to": "au-npp:exc.payment-initiation-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.payment-initiation-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.npp-payment-initiation-messages-v4", "section": "Background, and the assumptions and conditions under Technical Guidance", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Payment Initiation Messages, technical guidance v4.0 of 20 November 2025, read 2026-09-21. That no deadline exists is a statement about what the guidance does not contain [Inference]; no typed time window is carried, because there is no figure to type.", "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. Drafted 2026-09-21.", "source_edition": "NPP Payment Initiation Messages v4.0, dated 20 November 2025, uploaded March 2026, read 2026-09-21.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-payment-initiation-messages-v4", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "The Background section confirms pain.002 status report messages provide acknowledgements, rejections and settlement confirmations and are essential for tracking and reconciling payment instructions, and confirms an NPP FI's acceptance of pain.001 messages and provision of pain.002 messages to corporate and government customers is proprietary and at its discretion, with no deadline given for a status report anywhere in the document." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp-reject:AC02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC05", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC06", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC07", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC13", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC14", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC15", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AG01", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AG03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AGNT", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM01", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM06", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM09", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM12", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM19", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM21", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:BE06", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:BE08", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:BE22", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:CH20", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:CH21", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:CURR", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:DT02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:DT04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:FF10", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:MD01", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:NARR", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:NAUT", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:TD03", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "id": "rule.messages-the-interbank-reason-code-values-are-not-public", "rail": "au-npp", "class": "Rule", "name": "The interbank reason code values are in the procedures and are not published", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 6.3(a)(ii), 6.6 and 17.8(b)(i)", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payee-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified]. The code lists sit in the NPP Procedures Volumes 3, 6 and 9, which are participant material and were not consulted.", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "primary_not_public": true, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "au-npp:state.rejected-at-clearing", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC05", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC06", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC07", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC13", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC14", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC15", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AG01", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AG03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AGNT", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM01", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM06", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM09", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM12", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM19", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM21", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:BE06", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:BE08", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:BE22", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:CH20", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:CH21", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:CURR", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:DT02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:DT04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:FF10", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:MD01", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:NARR", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:NAUT", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:TD03", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "id": "rule.messages-the-payment-initiation-leg-is-proprietary", "rail": "au-npp", "class": "Rule", "name": "Whether an institution accepts a customer payment instruction at all is its own commercial matter", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-payment-initiation-messages-v4", "section": "Background, and the assumptions and conditions under Technical Guidance", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.payment-initiation-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Payment Initiation Messages, technical guidance v4.0 of 20 November 2025, published by Australian Payments Plus and NPP Australia, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "2019-11-22", "effective_to": null, "effective_note": "Effective since 2019-11-22: the guidance's own document control records version 1.0 on that date, and version 4.0 on 20 November 2025 Drafted 2026-09-21 from the guidance itself. It carries an acceptance block and a confidential footer while sitting on a public page with a plain download link; nothing in it is reproduced here.", "source_edition": "NPP Payment Initiation Messages v4.0, dated 20 November 2025, uploaded March 2026, read 2026-09-21.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-payment-initiation-messages-v4", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "The Background section confirms an NPP FI's acceptance of pain.001 payment instructions and its provision of pain.002 status reports to corporate and government customers are proprietary and at its discretion, that the guidance rests on publicly available ISO message schema guidance subject to additional proprietary requirements an FI may impose, and the Technical Guidance section confirms a reader must consult their NPP FI for specific requirements, validations, formats and supported features." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp-reject:AC02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC05", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC06", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC07", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC13", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC14", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC15", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AG01", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AG03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AGNT", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM01", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM06", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM09", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM12", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM19", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM21", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:BE06", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:BE08", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:BE22", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:CH20", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:CH21", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:CURR", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:DT02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:DT04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:FF10", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:MD01", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:NARR", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:NAUT", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:TD03", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.participants-a-connected-institution-cannot-clear", "id": "rule.participants-a-connected-institution-cannot-clear", "rail": "au-npp", "class": "Rule", "name": "A connected institution connects directly and may not clear or settle", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 4.1(b)(ii), 4.6(h) and 17.5(e)(i)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.connected-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.non-value-message", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 17.5(e) confirms a Connected Institution connects directly but has no right to submit clearing or settlement messages, and may instead take part in the Mandated Payments Service as a Payment Initiator or its agent, creating mandate records for Payer Customer authorisation and, once authorisation is recorded, sending Mandate Payment Initiation Requests. Regulation 4.6(h) confirms a Connected Institution must satisfy the same connection requirements set out in Regulation 4.3(a) to (e)." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.participants-a-settlement-participant-need-not-be-an-adi", "id": "rule.participants-a-settlement-participant-need-not-be-an-adi", "rail": "au-npp", "class": "Rule", "name": "A settlement participant need not be a bank", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 4.2(a) and 4.5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.settlement-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulations 4.2(a) and 4.5 confirm a person must be the RBA or an ADI, except a prospective Settlement Participant may instead be a body corporate carrying on business in Australia, and Regulation 4.5 states for the avoidance of doubt that a Settlement Participant is not required to be an ADI." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.participants-most-institutions-reach-the-platform-through-a-sponsor", "id": "rule.participants-most-institutions-reach-the-platform-through-a-sponsor", "rail": "au-npp", "class": "Rule", "name": "Most institutions reach the platform through a sponsor and are not participants at all", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 6.1(d)(i)(B) and (iv)(B), 17.1(d), and the definition of Sponsor", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.sponsor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.identified-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 6.1(d) confirms a sponsoring participant must satisfy itself that each Identified Institution it provides clearing or settlement services to has a compliance framework in place, and the definitions of Identified Institution and Sponsor confirm an Identified Institution does not connect directly and reaches the platform through an NPP Participant that provides it clearing or settlement services as its Sponsor." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.participants-no-public-list-by-class-exists", "id": "rule.participants-no-public-list-by-class-exists", "rail": "au-npp", "class": "Rule", "name": "No public list of participants by class exists", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 4.3(f), 4.4(b), 4.5 and 4.6, which define the classes without naming any member", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.nppa", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, which define the classes and name no member, read 2026-09-21. That no public list exists is a statement about what was not found rather than about what any source says [Inference]; the Reserve Bank's RITS membership list, which marks Fast Settlement Service participants, was not opened here.", "confidence": "low" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulations 4.3(f), 4.4(b), 4.5 and 4.6 define the eligibility criteria for each participant class without naming any member, confirming that nothing in the Regulations themselves identifies a Clearing Participant, a Connected Institution or an Identified Institution by name." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.participants-the-rules-are-a-contract-under-seal", "id": "rule.participants-the-rules-are-a-contract-under-seal", "rail": "au-npp", "class": "Rule", "name": "The rules take effect as a contract under seal between the operator and everybody else", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 4.2(d) and 4.6(d)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.nppa", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.full-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.connected-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.overlay-service-provider", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulations 4.2(d) and 4.6(d) confirm that on becoming an NPP Participant or Connected Institution, the Regulations and Procedures constitute a contract under seal between that party and NPPA and every current and future NPP Participant, Connected Institution and Overlay Service Provider." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.participants-three-classes-and-two-capabilities", "id": "rule.participants-three-classes-and-two-capabilities", "rail": "au-npp", "class": "Rule", "name": "Three participant classes cut across two capabilities: connecting, and being authorised to settle", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 4.2, 4.3, 4.4 and 4.5, and the definitions of each class", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.full-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.clearing-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.settlement-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulations 4.2 to 4.5 confirm a Full Participant must meet all Full Participant requirements including RBA authorisation to use the FSS, a Clearing Participant meets the same connection requirements but instead enters a proprietary settlement arrangement with another participant, and a Settlement Participant need only be RBA authorised to use the FSS without connecting directly, alongside the shared eligibility requirements in Regulation 4.2." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.recall-a-duplicate-or-error-payment-return-is-discretionary", "id": "rule.recall-a-duplicate-or-error-payment-return-is-discretionary", "rail": "au-npp", "class": "Rule", "name": "Returning a duplicate or error payment is at the receiving institution's discretion", "statement": "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.", "rests_on": "rule", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 6.4(c)(i) and 6.5(c)(i) and (ii)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payee-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.duplicate-or-error-payment-return-request", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulations 6.4(c) and 6.5(c) confirm that for a settled Duplicate Payment or a payment sent through the Payer Participant's own error, the Payer Participant may request return, the Payee Participant must acknowledge and assess, and the Regulations state in terms that the return is at the Payee Participant's discretion." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.recall-a-misdirected-payment-is-returned-if-the-payee-participant-is-satisfied", "id": "rule.recall-a-misdirected-payment-is-returned-if-the-payee-participant-is-satisfied", "rail": "au-npp", "class": "Rule", "name": "A misdirected payment is returned if the receiving institution is satisfied that is what it is", "statement": "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.", "rests_on": "rule", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 6.5(b) and its note, and the definition of Misdirected Payment", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payee-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.registering-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.misdirected-payment-return-request", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 6.5(b) and the definition of Misdirected Payment confirm a misdirected payment is one that went to the wrong account because the Registering Participant did not correctly register or maintain the Alias, that the Payer Participant may request return, and that the Payee Participant must acknowledge, assess, and effect a return if satisfied it is a Misdirected Payment." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.recall-a-mistaken-payment-must-be-assessed-and-returned-if-needed", "id": "rule.recall-a-mistaken-payment-must-be-assessed-and-returned-if-needed", "rail": "au-npp", "class": "Rule", "name": "A mistaken payment must be asked back, assessed with reasonable endeavours and returned if needed", "statement": "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.", "rests_on": "rule", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 6.5(a)(i) and (ii), and the definition of Mistaken Payment", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payee-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.mistaken-payment-return-request", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:rule.refund-the-sending-adi-must-investigate-and-ask-within-5-business-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 6.5(a) and the definition of Mistaken Payment confirm a mistaken payment is one a user as the ePayments Code defines that term sent to the wrong account by their own error, that the Payer Participant must request return, and that the Payee Participant must acknowledge, use reasonable endeavours to assess, advise whether and when it will return, and effect any necessary return." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.recall-a-request-for-payment-return-is-a-request-not-a-right", "id": "rule.recall-a-request-for-payment-return-is-a-request-not-a-right", "rail": "au-npp", "class": "Rule", "name": "A request for payment return asks the receiving institution to send a settled payment back", "statement": "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.", "rests_on": "rule", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "the definition of Request for Payment Return, and Regulation 6.5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payee-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "The definition of Request for Payment Return and Regulation 6.5 confirm it is a single message type used across three differently worded obligations on the Payee Participant, must for a Mistaken Payment, must if satisfied for a Misdirected Payment, and may for a Duplicate Payment, Error Payment or Payer Participant error." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.recall-the-payer-participant-carries-its-own-customers-loss", "id": "rule.recall-the-payer-participant-carries-its-own-customers-loss", "rail": "au-npp", "class": "Rule", "name": "The paying institution owes its own customer whatever the receiving institution decides", "statement": "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.", "rests_on": "rule", "facet": "recall", "parameters": { "liability_holder": { "role": "au-npp:role.payer-participant", "condition": "the payment was a settled duplicate, or was sent as a result of the paying institution's own error", "text": "Full liability to compensate the payer, independent of whether the receiving institution returns the money." } }, "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 6.4(c)(ii)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.duplicate-or-error-payment-return-request", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 6.4(c)(ii) confirms the Payer Participant bears full liability to compensate the Payer for the value of a settled Duplicate Payment or a payment sent through the Payer Participant's own error, independent of the Payee Participant's discretion to return it." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.recall-the-payer-participant-indemnifies-a-good-faith-return", "id": "rule.recall-the-payer-participant-indemnifies-a-good-faith-return", "rail": "au-npp", "class": "Rule", "name": "The paying institution indemnifies a receiving institution that returns a payment properly", "statement": "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.", "rests_on": "rule", "facet": "recall", "parameters": { "liability_holder": { "role": "au-npp:role.payer-participant", "condition": "the receiving institution used reasonable endeavours to assess a mistaken payment, or returned a duplicate or error payment in good faith and without negligence, and gives written evidence of its loss and mitigates it", "text": "The paying institution carries the cost of a properly made return. Where the receiving institution did not assess a mistaken payment properly before returning it, the loss stays with the receiving institution instead." } }, "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 6.5(a)(iii) and (iv), and 6.5(c)(iii)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payee-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.mistaken-payment-return-request", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulations 6.5(a)(iii) and (iv) and 6.5(c)(iii) confirm the Payer Participant indemnifies a Payee Participant that used reasonable endeavours to assess a Mistaken Payment before returning it, and one that returns a Duplicate or Error Payment in good faith and without negligence, conditioned on written evidence of the loss and reasonable mitigation, and that a Payee Participant which fails to assess a Mistaken Payment properly gets no indemnity and bears the loss itself." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.recall-there-is-no-recall-and-no-cancellation-message", "id": "rule.recall-there-is-no-recall-and-no-cancellation-message", "rail": "au-npp", "class": "Rule", "name": "There is no recall and no cancellation message on this rail", "statement": "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.", "rests_on": "rule", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 6.2(a) and 6.5, and the definition of Request for Payment Return", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:rule.finality-no-cancel-or-recall-once-the-message-is-in-the-gateway", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:rule.no-recall-and-no-cancellation-once-submitted", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 6.2(a) confirms there is no cancel or recall of a Clearing Request once it is in the Payer Participant's gateway, and Regulation 6.5 and the definition of Request for Payment Return confirm the only message reaching back toward a settled payment is a request the Payee Participant may, must if satisfied, or must act on, not a right to have funds returned." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.finality-no-cancel-or-recall-once-the-message-is-in-the-gateway", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.refund-an-on-screen-warning-is-required-but-not-for-payid", "id": "rule.refund-an-on-screen-warning-is-required-but-not-for-payid", "rail": "au-npp", "class": "Rule", "name": "A subscriber must warn the payer on screen to check the details, and that duty does not cover PayID", "statement": "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.", "rests_on": "guidance", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "au-npp:src.epayments-code-2022", "section": "clauses 27.1, 27.2 and the note to clause 27.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.subscriber", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-customer", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "ASIC's ePayments Code as published 2 June 2022, at the clauses named in the record's sourced_from link, read 2026-09-21.", "confidence": "high" }, "currency": { "effective_since": "2022-06-02", "effective_to": null, "effective_note": "Drafted 2026-09-21 from ASIC's own current text of the ePayments Code. The Code is voluntary and binds subscribers only; which institutions subscribe was not established here.", "source_edition": "ePayments Code as published by ASIC on 2 June 2022, read 2026-09-21.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.epayments-code-2022", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Confirms a subscriber must clearly warn users to check that the BSB number or identifier is correct, that funds sent to a wrong account may not be recoverable, and that names and identifiers are not matched or verified; that where practicable this warning appears on screen during a pay anyone transaction using a BSB and account number, before the transaction is finally confirmed and while the user can still cancel or correct it; and that a note to the clause states the requirements do not apply to a transaction using a PayID." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.refund-reported-after-7-months-only-with-consent", "id": "rule.refund-reported-after-7-months-only-with-consent", "rail": "au-npp", "class": "Rule", "name": "Reported after 7 months, and the money comes back only if the recipient agrees", "statement": "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.", "rests_on": "guidance", "facet": "refund", "parameters": { "time_window": { "count": 7, "unit": "month", "from": "settlement_date", "actor": "au-npp:role.payer-customer", "text": "Beyond 7 months from the payment, return depends on the unintended recipient consenting." } }, "relations": [ { "type": "sourced_from", "to": "au-npp:src.epayments-code-2022", "section": "clauses 32.1 to 32.4, and clauses 30.3 and 31.5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.receiving-adi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.mistaken-internet-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "ASIC's ePayments Code as published 2 June 2022, at the clauses named in the record's sourced_from link, read 2026-09-21.", "confidence": "high" }, "currency": { "effective_since": "2022-06-02", "effective_to": null, "effective_note": "Drafted 2026-09-21 from ASIC's own current text of the ePayments Code. The Code is voluntary and binds subscribers only; which institutions subscribe was not established here.", "source_edition": "ePayments Code as published by ASIC on 2 June 2022, read 2026-09-21.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.epayments-code-2022", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Confirms that for a report made more than 7 months after the payment, a satisfied receiving institution must seek the unintended recipient's consent before any funds move back, and an unsatisfied receiving institution may also seek consent but is not obliged to act further; the same consent step also appears at the earlier reporting tiers when the receiving institution is not satisfied a mistaken payment occurred." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.refund-reported-between-10-business-days-and-7-months", "id": "rule.refund-reported-between-10-business-days-and-7-months", "rail": "au-npp", "class": "Rule", "name": "Reported between 10 business days and 7 months, and the recipient gets a chance to show entitlement first", "statement": "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.", "rests_on": "guidance", "facet": "refund", "parameters": { "time_window": { "count": 2, "unit": "business_day", "from": "notice_of_refusal", "actor": "au-npp:role.receiving-adi", "text": "2 business days to return the funds, counted from the expiry of the ten further business days in which the unintended recipient could establish entitlement. The receiving institution must finish its investigation within ten business days of the request before that period starts." } }, "relations": [ { "type": "sourced_from", "to": "au-npp:src.epayments-code-2022", "section": "clauses 31.1 to 31.6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.receiving-adi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.sending-adi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.mistaken-internet-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "ASIC's ePayments Code as published 2 June 2022, at the clauses named in the record's sourced_from link, read 2026-09-21.", "confidence": "high" }, "currency": { "effective_since": "2022-06-02", "effective_to": null, "effective_note": "Drafted 2026-09-21 from ASIC's own current text of the ePayments Code. The Code is voluntary and binds subscribers only; which institutions subscribe was not established here.", "source_edition": "ePayments Code as published by ASIC on 2 June 2022, read 2026-09-21.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.epayments-code-2022", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Confirms that for a report made between 10 business days and 7 months after the payment, the receiving institution must complete its investigation within 10 business days of the request, then if satisfied must prevent withdrawal for a further 10 business days while giving the unintended recipient a chance to establish entitlement, and must return the funds within 2 business days after that further period expires if entitlement is not established." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.refund-reported-within-10-business-days-the-money-comes-back", "id": "rule.refund-reported-within-10-business-days-the-money-comes-back", "rail": "au-npp", "class": "Rule", "name": "Reported inside 10 business days, and the money simply comes back", "statement": "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.", "rests_on": "guidance", "facet": "refund", "parameters": { "time_window": { "count": 10, "unit": "business_day", "from": "receipt", "actor": "au-npp:role.receiving-adi", "text": "The tier applies where the customer reported within 10 business days of making the payment. The receiving institution then returns the funds within 5 business days of the request if practicable, and in any case within 10." } }, "relations": [ { "type": "sourced_from", "to": "au-npp:src.epayments-code-2022", "section": "clauses 30.1, 30.2 and 30.4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.receiving-adi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.sending-adi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.mistaken-internet-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "ASIC's ePayments Code as published 2 June 2022, at the clauses named in the record's sourced_from link, read 2026-09-21.", "confidence": "high" }, "currency": { "effective_since": "2022-06-02", "effective_to": null, "effective_note": "Drafted 2026-09-21 from ASIC's own current text of the ePayments Code. The Code is voluntary and binds subscribers only; which institutions subscribe was not established here.", "source_edition": "ePayments Code as published by ASIC on 2 June 2022, read 2026-09-21.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.epayments-code-2022", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Confirms that where the report is made within 10 business days and both institutions are satisfied funds are sufficient, the receiving institution returns the funds within 5 business days of the request if practicable and otherwise within a maximum of 10, and the sending institution then returns the funds to its customer as soon as practicable." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.refund-the-scheme-gives-a-customer-no-refund-right", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.refund-the-outcome-in-writing-within-30-business-days", "id": "rule.refund-the-outcome-in-writing-within-30-business-days", "rail": "au-npp", "class": "Rule", "name": "The sending institution must tell the customer the outcome in writing within 30 business days", "statement": "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.", "rests_on": "guidance", "facet": "refund", "parameters": { "time_window": { "count": 30, "unit": "business_day", "from": "receipt", "actor": "au-npp:role.sending-adi", "text": "30 business days from the day the report was made, to tell the customer the outcome in writing." } }, "relations": [ { "type": "sourced_from", "to": "au-npp:src.epayments-code-2022", "section": "clauses 35.1, 35.2, 36.1 to 36.3 and 36.5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.sending-adi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.afca", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.mistaken-internet-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "ASIC's ePayments Code as published 2 June 2022, at the clauses named in the record's sourced_from link, read 2026-09-21.", "confidence": "high" }, "currency": { "effective_since": "2022-06-02", "effective_to": null, "effective_note": "Drafted 2026-09-21 from ASIC's own current text of the ePayments Code. The Code is voluntary and binds subscribers only; which institutions subscribe was not established here.", "source_edition": "ePayments Code as published by ASIC on 2 June 2022, read 2026-09-21.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.epayments-code-2022", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Confirms the sending institution must tell the customer the outcome in writing within 30 business days of the report, that the written communication must state the customer's right to complain about how the report was handled, that the sending institution must handle such a complaint under its own internal dispute resolution process and must not require the customer to complain to the receiving institution, that a customer unsatisfied with the complaint outcome must be able to take it to AFCA, and that non-cooperation by the receiving institution is expressly not a relevant consideration in judging the sending institution's own compliance." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.refund-the-receiving-adi-answers-within-5-business-days", "id": "rule.refund-the-receiving-adi-answers-within-5-business-days", "rail": "au-npp", "class": "Rule", "name": "The receiving institution must acknowledge the request and say whether the money is there, within 5 business days", "statement": "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.", "rests_on": "guidance", "facet": "refund", "parameters": { "time_window": { "count": 5, "unit": "business_day", "from": "receipt", "actor": "au-npp:role.receiving-adi", "text": "5 business days from receiving the sending institution's request, to acknowledge it and to report whether the funds are there." } }, "relations": [ { "type": "sourced_from", "to": "au-npp:src.epayments-code-2022", "section": "clause 29.2(b)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.receiving-adi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.mistaken-internet-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "ASIC's ePayments Code as published 2 June 2022, at the clauses named in the record's sourced_from link, read 2026-09-21.", "confidence": "high" }, "currency": { "effective_since": "2022-06-02", "effective_to": null, "effective_note": "Drafted 2026-09-21 from ASIC's own current text of the ePayments Code. The Code is voluntary and binds subscribers only; which institutions subscribe was not established here.", "source_edition": "ePayments Code as published by ASIC on 2 June 2022, read 2026-09-21.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.epayments-code-2022", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Confirms that within 5 business days of receiving the sending institution's request, the receiving institution must acknowledge it and advise whether the unintended recipient's account holds sufficient funds to cover the payment." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.refund-the-scheme-gives-a-customer-no-refund-right", "id": "rule.refund-the-scheme-gives-a-customer-no-refund-right", "rail": "au-npp", "class": "Rule", "name": "The scheme gives a customer no refund right of their own", "statement": "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.", "rests_on": "rule", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 6.5 and 6.6, and their notes", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-customer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:consumer-law", "note": "The right a customer can actually use sits in the ePayments Code rather than in the rulebook. This is a pointer inside one rail rather than a deferral to another rail, because no source points the question anywhere outside Australia.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:rule.refund-reported-within-10-business-days-the-money-comes-back", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulations 6.5 and 6.6 confirm every return route runs between the Payer Participant and the Payee Participant, phrased as must, must if satisfied, or may, and none of them gives the Payer Customer a right of their own to have a payment returned." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.refund-the-sending-adi-must-investigate-and-ask-within-5-business-days", "id": "rule.refund-the-sending-adi-must-investigate-and-ask-within-5-business-days", "rail": "au-npp", "class": "Rule", "name": "The sending institution must investigate, and if satisfied must ask for the money back within 5 business days", "statement": "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.", "rests_on": "guidance", "facet": "refund", "parameters": { "time_window": { "count": 5, "unit": "business_day", "from": "receipt", "actor": "au-npp:role.sending-adi", "text": "As soon as reasonably possible and no later than 5 business days from the customer's report. The Code's own note says industry practice is to start within 2 business days." } }, "relations": [ { "type": "sourced_from", "to": "au-npp:src.epayments-code-2022", "section": "clauses 29.1, 29.2(a) and 29.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.sending-adi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.mistaken-internet-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "ASIC's ePayments Code as published 2 June 2022, at the clauses named in the record's sourced_from link, read 2026-09-21.", "confidence": "high" }, "currency": { "effective_since": "2022-06-02", "effective_to": null, "effective_note": "Drafted 2026-09-21 from ASIC's own current text of the ePayments Code. The Code is voluntary and binds subscribers only; which institutions subscribe was not established here.", "source_edition": "ePayments Code as published by ASIC on 2 June 2022, read 2026-09-21.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.epayments-code-2022", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Confirms the sending institution must investigate a reported mistaken internet payment, and if satisfied must ask the receiving institution for the funds back as soon as reasonably possible and no later than 5 business days from the report, with no further action required if not satisfied." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.recall-a-mistaken-payment-must-be-assessed-and-returned-if-needed", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.refund-where-the-funds-are-short-the-receiving-adi-weighs-the-two-customers", "id": "rule.refund-where-the-funds-are-short-the-receiving-adi-weighs-the-two-customers", "rail": "au-npp", "class": "Rule", "name": "Where the money is not all there, the receiving institution weighs both customers and decides how much to pursue", "statement": "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.", "rests_on": "guidance", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "au-npp:src.epayments-code-2022", "section": "clauses 34.1 to 34.6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.receiving-adi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.mistaken-internet-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "ASIC's ePayments Code as published 2 June 2022, at the clauses named in the record's sourced_from link, read 2026-09-21.", "confidence": "high" }, "currency": { "effective_since": "2022-06-02", "effective_to": null, "effective_note": "Drafted 2026-09-21 from ASIC's own current text of the ePayments Code. The Code is voluntary and binds subscribers only; which institutions subscribe was not established here.", "source_edition": "ePayments Code as published by ASIC on 2 June 2022, read 2026-09-21.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.epayments-code-2022", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Confirms that where sufficient funds are not available, the receiving institution must exercise a discretion, weighing the interests of the sending customer and the unintended recipient and what it reasonably knows of the circumstances, to decide whether to pursue return of the full amount, a partial amount, or none, guided by a non-exhaustive list of factors, and that where it decides to pursue a return it must use reasonable endeavours to retrieve the funds, for example by facilitating repayment in instalments." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.return-a-return-is-a-new-payment-going-the-other-way", "id": "rule.return-a-return-is-a-new-payment-going-the-other-way", "rail": "au-npp", "class": "Rule", "name": "A return is a new payment in the opposite direction, never a reversal", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "the definition of NPP Payment Return, and Regulations 6.5 and 6.6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payee-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.npp-payment-return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.unsolicited-return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:rule.credit-payment-recovery-is-not-a-reversal", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "The definition of NPP Payment Return confirms it is a distinct pacs.004 message a Payee Participant sends to effect the return of a settled payment, whether unsolicited or in answer to a Request for Payment Return, and Regulations 6.5 and 6.6 confirm the original payment is not reversed by it." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:state.returned", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.return-a-zero-value-return-is-forbidden", "id": "rule.return-a-zero-value-return-is-forbidden", "rail": "au-npp", "class": "Rule", "name": "A zero value return may not be sent", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 6.1(c)(ii)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payee-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.npp-payment-return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:rule.limits-a-zero-value-payment-is-forbidden", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 6.1(c)(ii) confirms a Payee Participant must not submit an NPP Payment Return with a zero value, and no provision read addresses a partial return." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.limits-a-zero-value-payment-is-forbidden", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.return-an-unsolicited-return-is-the-payee-participants-own-choice", "id": "rule.return-an-unsolicited-return-is-the-payee-participants-own-choice", "rail": "au-npp", "class": "Rule", "name": "An unsolicited return, and what the account holder is told about it, is the receiving institution's own matter", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "the note to Regulation 6.6, and the note to Regulation 6.5(c)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payee-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.unsolicited-return", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "The notes to Regulations 6.6 and 6.5(c) confirm that whether and how a Payee Participant notifies or seeks prior authorisation from its account holder before returning a payment, whether unsolicited or requested, is a proprietary matter beyond any obligation the statute, general law, Regulations or Procedures impose." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.return-only-a-cleared-payment-may-be-returned", "id": "rule.return-only-a-cleared-payment-may-be-returned", "rail": "au-npp", "class": "Rule", "name": "Only a cleared payment may be returned, and only by the return message", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 6.6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payee-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.npp-payment-return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.unsolicited-return", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 6.6 confirms a Payee Participant may only return a Cleared NPP Payment by initiating an NPP Payment Return complying with the Procedures, with no other route or message named." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:state.returned", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.return-windows-and-deadlines-are-not-public", "id": "rule.return-windows-and-deadlines-are-not-public", "rail": "au-npp", "class": "Rule", "name": "Every return window, acknowledgement deadline and return deadline is in the procedures and is not public", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 6.5(a)(i) to (ii)(D), 6.5(b)(ii), 6.5(c)(ii) and 6.6", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payee-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.mistaken-payment-return-request", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified]. The timeframes sit in NPP Procedures Volume 9, which is participant material and was not consulted.", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "primary_not_public": true, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "au-npp:state.returned", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.settlement-a-clearing-participant-settles-through-another-participant", "id": "rule.settlement-a-clearing-participant-settles-through-another-participant", "rail": "au-npp", "class": "Rule", "name": "A clearing participant settles through a private arrangement with another participant", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 4.4(a) and (b)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.clearing-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 4.4 confirms a Clearing Participant must comply with all the Full Participant connection requirements in Regulation 4.3(a) to (e) and must enter a proprietary arrangement with an NPP Participant to have its payments settled under Part 7." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.settlement-authorisation-by-the-rba-is-required-to-settle", "id": "rule.settlement-authorisation-by-the-rba-is-required-to-settle", "rail": "au-npp", "class": "Rule", "name": "Only an institution the Reserve Bank has authorised may settle, and it must stay authorised", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 7.1, 4.3(f) and 4.5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.full-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.settlement-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.rba-fss-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulations 4.3(f) and 4.5 confirm a Full Participant and a Settlement Participant must be authorised by the RBA to use the FSS for settlement of NPP Payments." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.settlement-contingency-and-indeterminate-status-sit-in-the-procedures", "id": "rule.settlement-contingency-and-indeterminate-status-sit-in-the-procedures", "rail": "au-npp", "class": "Rule", "name": "What happens when settlement fails or its status is unknown is in the procedures, and is not public", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 7.5 and 7.6", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.full-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.clearing-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified]. The substance sits in NPP Procedures Volumes 3 and 10, which are participant material and were not consulted.", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "primary_not_public": true, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.settlement-esa-funds-split-between-fss-and-everything-else", "id": "rule.settlement-esa-funds-split-between-fss-and-everything-else", "rail": "au-npp", "class": "Rule", "name": "A participant may split its settlement account funds between the instant service and everything else", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "au-npp:src.rba-about-rits", "section": "About RITS, on the allocation of exchange settlement account funds", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.rba-esa-provider", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.full-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.settlement-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The Reserve Bank of Australia's About RITS page, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the page does not date this arrangement", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the Reserve Bank's own description of the accounts it holds.", "source_edition": "Reserve Bank of Australia, About RITS, live page read 2026-09-21.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.rba-about-rits", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "The RBA's About RITS page confirms the funds of an ESA holder that participates in the FSS may be allocated to be available either for testing and settling FSS transactions or for all other transactions." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.settlement-no-liquidity-management-features", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.settlement-no-liquidity-management-features", "id": "rule.settlement-no-liquidity-management-features", "rail": "au-npp", "class": "Rule", "name": "The settlement service carries no liquidity management features, deliberately", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "au-npp:src.rba-about-rits", "section": "About RITS, on liquidity management features", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.rba-fss-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:rule.settlement-esa-funds-split-between-fss-and-everything-else", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The Reserve Bank of Australia's About RITS page, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the page does not date this design choice", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the Reserve Bank's own description of the service it operates.", "source_edition": "Reserve Bank of Australia, About RITS, live page read 2026-09-21.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.rba-about-rits", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "The RBA's About RITS page confirms the FSS does not include liquidity management features, and states the reason is to increase the speed of payment processing." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:rule.settlement-per-payment-rtgs-across-exchange-settlement-accounts", "id": "rule.settlement-per-payment-rtgs-across-exchange-settlement-accounts", "rail": "au-npp", "class": "Rule", "name": "Every payment settles on its own, in central bank money, across exchange settlement accounts", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 7.3(a) to (c)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.rba-about-rits", "section": "About RITS", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.full-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.settlement-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.rba-esa-provider", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.bsct", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The Reserve Bank of Australia's About RITS page, read 2026-09-21, together with the NPP Regulations v21.0 of 24 September 2024 at the regulation named in the record's links.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 7.3(a) to (c) confirms each Cleared NPP Payment is submitted for settlement via the FSS by debiting and crediting the ESAs of the participants responsible for it, subject to applicable law and the RITS Regulations." }, { "source": "au-npp:src.rba-about-rits", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "The RBA's About RITS page confirms the FSS settles NPP transactions on an RTGS basis, individually rather than by netting." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.finality-rtgs-settlement-is-final-under-the-netting-act", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:state.applied-to-the-payee-account", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:state.settled", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.settlement-the-fss-tests-funds-and-settles-or-rejects", "id": "rule.settlement-the-fss-tests-funds-and-settles-or-rejects", "rail": "au-npp", "class": "Rule", "name": "The settlement service tests the paying institution's funds and either settles or rejects", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "au-npp:src.rba-about-rits", "section": "About RITS, on how the Fast Settlement Service handles a settlement request", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.rba-fss-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "au-npp:exc.settlement-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The Reserve Bank of Australia's About RITS page, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the page does not date this description", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the Reserve Bank's own description of the service it operates.", "source_edition": "Reserve Bank of Australia, About RITS, live page read 2026-09-21.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.rba-about-rits", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "The RBA's About RITS page confirms the FSS tests that the paying ESA holder has sufficient funds and either settles the payment if funds are available or otherwise rejects it." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:state.voided-by-settlement-rejection", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:rule.settlement-the-gateway-generates-a-settlement-request-automatically", "id": "rule.settlement-the-gateway-generates-a-settlement-request-automatically", "rail": "au-npp", "class": "Rule", "name": "The paying institution's gateway generates a settlement request for every cleared payment by itself", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 6.2(c) and 7.2(a) to (c)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.full-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.clearing-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulation named in the record's sourced_from link, read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulations 6.2(c) and 7.2(a) to (c) confirm the Payer Participant's gateway automatically generates and submits a Settlement Request for each Cleared NPP Payment within the configurable timeout the Procedures prescribe, and that a Full or Clearing Participant must configure its gateway to do so, to receive Settlement Notifications, and to queue Settlement Requests." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:state.cleared", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:src.auspayplus-payto-faqs", "id": "src.auspayplus-payto-faqs", "rail": "au-npp", "class": "RuleSource", "name": "Australian Payments Plus, PayTo FAQs", "summary": "The operator's parent describing PayTo to the people who use it. It says a PayTo agreement is an agreement between the payer and a business in which the payer authorises the amount, purpose and frequency, that a business starts the agreement and the payer authorises it in online banking, that the payer can pause, resume or cancel there, that a change of amount or frequency has to come from the business as a fresh agreement to authorise, and that pausing or cancelling does not change the payer's contract with the business. On direct debits moving across it says the payer gets 14 days notice, may opt out during that period, does not re-approve because the existing direct debit was already authorised, and that the business allows 5 days before the first debit.", "publisher": "Australian Payments Plus Limited", "url": "https://www.auspayplus.com.au/solutions/payto-faqs", "source_class": "public_primary", "kind": "web_page", "edition": "live page, read 2026-09-21", "access": "open", "family": "auspayplus", "consulted_on": "2026-09-21", "relations": [], "basis": { "sources": "The document itself, fetched and read on 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-21 for the au-npp rail. A RuleSource describes one edition of one document; its status stays draft and a watch dates it through consulted_on.", "source_edition": "live page, read 2026-09-21", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "au-npp:mandate.authorised-payment-mandate", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:mandate.migrated-ddr-mandate", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:role.auspayplus", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:role.payer-customer", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.decision-points-the-payer-customer-authorises-pauses-or-cancels-a-mandate", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.mandate-an-amount-or-frequency-change-comes-from-the-business", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.mandate-fourteen-days-notice-before-a-migrated-mandate-is-created", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.mandate-the-payer-customer-can-view-suspend-cancel-and-amend", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:state.mandate-active", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:state.mandate-cancelled", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:state.mandate-declined", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:state.mandate-suspended", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:src.epayments-code-2022", "id": "src.epayments-code-2022", "rail": "au-npp", "class": "RuleSource", "name": "ePayments Code", "summary": "ASIC's voluntary code for electronic payments, citable by clause. Chapter C allocates loss between a subscriber and its customer for transactions the customer did not authorise, and says plainly that a transaction the customer performed themselves, or that somebody performed with the customer's knowledge and consent, is not one of them. Chapter E sets out the mistaken internet payment process that Australian banks run when a payer puts in the wrong account details, with its reporting tiers and its clocks. The Code binds subscribers only.", "publisher": "Australian Securities and Investments Commission", "url": "https://download.asic.gov.au/media/lloeicwb/epayments-code-published-02-june-2022.pdf", "source_class": "authoritative_primary", "kind": "regulator_code", "edition": "published 2 June 2022", "access": "open", "family": "asic", "consulted_on": "2026-09-21", "relations": [], "basis": { "sources": "The document itself, fetched and read on 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-21 for the au-npp rail. A RuleSource describes one edition of one document; its status stays draft and a watch dates it through consulted_on.", "source_edition": "published 2 June 2022", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "au-npp:exc.mistaken-internet-payment", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:exc.unauthorised-transaction-claim", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:role.afca", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:role.asic", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:role.receiving-adi", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:role.sending-adi", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:role.subscriber", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.consumer-law-afca-hears-a-mistaken-payment-complaint", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.consumer-law-the-epayments-code-is-voluntary", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.liability-a-deceived-payer-is-not-an-unauthorised-transaction", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.liability-australia-has-no-mandatory-scam-reimbursement-rule", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.liability-the-holder-is-liable-where-the-subscriber-proves-contribution", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.liability-the-holder-is-not-liable-where-an-identifier-alone-can-pay", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.liability-the-residual-cap-is-150-dollars", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.refund-an-on-screen-warning-is-required-but-not-for-payid", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.refund-reported-after-7-months-only-with-consent", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.refund-reported-between-10-business-days-and-7-months", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.refund-reported-within-10-business-days-the-money-comes-back", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.refund-the-outcome-in-writing-within-30-business-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.refund-the-receiving-adi-answers-within-5-business-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.refund-the-sending-adi-must-investigate-and-ask-within-5-business-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.refund-where-the-funds-are-short-the-receiving-adi-weighs-the-two-customers", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "au-npp:src.npp-payment-initiation-messages-v4", "id": "src.npp-payment-initiation-messages-v4", "rail": "au-npp", "class": "RuleSource", "name": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0", "summary": "The only code list the governing authority publishes. It gives field by field guidance for the pain.001 payment instruction a corporate or government customer sends its own institution and the pain.002 status report the institution sends back, covering ordinary NPP payments and PayTo payments. Appendix E carries 4 status code values and Appendix F carries 33 reason code values. Its own background section says that an institution's acceptance of pain.001 and provision of pain.002 is proprietary and at that institution's discretion, and a note under each appendix says an institution may offer alternative values. The document opens with an acceptance block, whose terms are warranty and liability disclaimers and intellectual property notices, and every page footer reads Confidential while the file sits on a public page with a plain download link.", "publisher": "Australian Payments Plus Limited and NPP Australia Limited", "url": "https://www.auspayplus.com.au/wp-content/uploads/2026/03/NPP-payment-initiation-V4.0.pdf", "source_class": "authoritative_primary", "kind": "technical_guidance", "edition": "v4.0, 20 November 2025, uploaded March 2026", "access": "terms", "family": "auspayplus", "consulted_on": "2026-09-21", "relations": [], "basis": { "sources": "The document itself, fetched and read on 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-21 for the au-npp rail. A RuleSource describes one edition of one document; its status stays draft and a watch dates it through consulted_on.", "source_edition": "v4.0, 20 November 2025, uploaded March 2026", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "au-npp:exc.payment-initiation-rejection", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:role.auspayplus", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.messages-four-status-code-values-on-the-initiation-leg", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.messages-iso-20022-from-launch", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:txn.payment-initiation-instruction", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "au-npp:src.npp-payto-service-overview-v2", "id": "src.npp-payto-service-overview-v2", "rail": "au-npp", "class": "RuleSource", "name": "NPP Australia, PayTo Service Overview v2.0, November 2021", "summary": "NPP Australia's own introduction to PayTo for businesses and institutions, linked from the AP+ PayTo FAQs. It explains that a PayTo agreement is created in and held by the Mandate Management Service, that the payer's bank is told a new agreement awaits the payer's authorisation and confirms it back, and that the agreement can then be amended (some amendments needing fresh authorisation), paused (and reactivated by whoever paused it), cancelled (after which no payment can be initiated under it) and transferred to another bank. It walks through worked examples of the create, authorise and pay sequence. It is not the rulebook and it predates the NPP Regulations edition the corpus reads.", "publisher": "NPP Australia Limited", "url": "https://www.auspayplus.com.au/wp-content/uploads/2025/07/PayTo-Service-Overview-Nov-2021-2.0.pdf", "source_class": "public_primary", "kind": "overview", "edition": "v2.0, November 2021 (PDF created 2021-11-23), re-uploaded July 2025", "access": "open", "family": "auspayplus", "consulted_on": "2026-09-23", "relations": [], "basis": { "sources": "The document itself, 22 pages, fetched with a plain GET from the link on the AP+ PayTo FAQs page and read on 2026-09-23. Page 2 carries placeholder text from the design template; the pages cited by records are 5 to 10 and the worked examples on 18 to 21.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-23 by the product view slice 3 drafting session for the PayTo mandate states. A RuleSource describes one edition of one document; its status stays draft and a watch dates it through consulted_on.", "source_edition": "v2.0, November 2021", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "au-npp:state.mandate-active", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:state.mandate-awaiting-authorisation", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:state.mandate-cancelled", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:state.mandate-suspended", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "au-npp:src.npp-product-rules-v31", "id": "src.npp-product-rules-v31", "rail": "au-npp", "class": "RuleSource", "name": "NPP Product Rules v.31, redacted, the current edition of the rulebook", "summary": "The current edition of the document above, under its current name, published openly by NPPA in September 2026. It cannot be read by an agent or by any text tool: all 102 pages carry a single image each, no page has a font resource, and no character can be extracted. It is recorded so that every record on this rail can name the edition it does not rest on, and so a watch can test each month whether a text edition has appeared.", "publisher": "NPP Australia Limited", "url": "https://www.auspayplus.com.au/wp-content/uploads/2026/09/NPP-Product-Rules-v.31_Redacted.pdf", "source_class": "authoritative_primary", "kind": "rulebook", "edition": "v.31, uploaded September 2026", "access": "open", "family": "auspayplus", "consulted_on": "2026-09-21", "relations": [], "basis": { "sources": "The document itself, fetched and read on 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-21 for the au-npp rail. A RuleSource describes one edition of one document; its status stays draft and a watch dates it through consulted_on.", "source_edition": "v.31, uploaded September 2026", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rail.au-npp", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:src.npp-regulations-v21", "id": "src.npp-regulations-v21", "rail": "au-npp", "class": "RuleSource", "name": "Regulations for the New Payments Platform, v21.0, public version", "summary": "The scheme's own rulebook under its former name, cited by regulation number. It sets out who may participate and on what terms, how a payment is cleared and when it becomes irrevocable, how it settles across the Fast Settlement Service, how the Addressing Service and PayID work, the Mandated Payments Service and the Mandate Management Service behind PayTo, and the Confirmation of Payee service. Regulation 6.9 and Annexure C are marked redacted, and one cross reference in Regulation 17.10 points at a regulation number the redaction removed. It is superseded by NPP Product Rules v.31, which cannot be read.", "publisher": "NPP Australia Limited", "url": "https://www.auspayplus.com.au/wp-content/uploads/2024/10/NPP-Regulations-v21.0_Public_version.pdf", "source_class": "authoritative_primary", "kind": "rulebook", "edition": "v21.0, 24 September 2024; the Regulations commenced 1 July 2017", "access": "open", "family": "auspayplus", "consulted_on": "2026-09-21", "relations": [], "basis": { "sources": "The document itself, fetched and read on 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-21 for the au-npp rail. A RuleSource describes one edition of one document; its status stays draft and a watch dates it through consulted_on.", "source_edition": "v21.0, 24 September 2024; the Regulations commenced 1 July 2017", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rail.au-npp", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:exc.clearing-rejection", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:exc.duplicate-or-error-payment-return-request", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:exc.mandate-claim", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:exc.misdirected-payment-return-request", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:exc.mistaken-payment-return-request", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:exc.settlement-rejection", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:exc.unsolicited-return", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:mandate.authorised-payment-mandate", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:mandate.debtor-payment-arrangement", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:mandate.migrated-ddr-mandate", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:role.clearing-participant", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:role.confirmed-data-holder", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:role.connected-institution", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:role.full-participant", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:role.identified-institution", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:role.initiating-participant", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:role.mps-user", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:role.nppa", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:role.overlay-service-provider", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:role.payee-customer", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:role.payee-participant", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:role.payer-customer", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:role.payer-participant", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:role.payment-initiator", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:role.rba-esa-provider", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:role.rba-fss-operator", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:role.registering-participant", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:role.settlement-participant", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:role.sponsor", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.consumer-law-the-epayments-code-is-voluntary", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.decision-points-the-payee-participant-accepts-or-rejects", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.decision-points-the-payer-acts-on-a-confirmation-of-payee-outcome", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.decision-points-the-payer-customer-authorises-pauses-or-cancels-a-mandate", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.decision-points-the-payer-participant-may-seek-confirmation-of-a-migrated-mandate", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.decision-points-the-payer-participant-screens-before-it-sends", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.finality-a-cleared-payment-the-fss-rejects-is-void", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.finality-cleared-means-the-payee-participant-accepted-it", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.finality-irrevocable-on-settlement-in-the-fss", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.finality-no-cancel-or-recall-once-the-message-is-in-the-gateway", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.finality-the-payer-participant-alone-decides-to-replay-or-retry", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.hours-clearing-and-settlement-run-24-hours-every-day", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.hours-response-timeout-values-are-not-public", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.hours-service-availability-targets-are-not-public", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.liability-a-registering-participant-indemnifies-a-misdirected-payment", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.liability-a-sponsor-takes-full-risk-on-the-users-it-sponsors", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.liability-the-initiating-participant-indemnifies-against-mandate-claims", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.limits-a-zero-value-payment-is-forbidden", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.limits-nppa-may-direct-value-limits-for-capacity", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.limits-participants-set-their-own-customer-limits", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.limits-the-scheme-sets-no-maximum-value", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.mandate-a-mandate-is-a-record-in-the-scheme-operators-database", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.mandate-a-mandate-may-be-ported-to-another-participant", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.mandate-a-migrated-mandate-claim-is-deemed-substantiated", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.mandate-a-migrated-mandate-is-created-without-a-consent-step", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.mandate-a-request-may-not-be-sent-unless-the-mandate-is-active", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.mandate-an-amount-or-frequency-change-comes-from-the-business", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-an-authorised-mandate-claim-is-deemed-substantiated-by-the-record", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.mandate-authorisation-is-delivered-in-near-real-time", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.mandate-data-is-confidential-to-the-parties", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.mandate-five-days-before-a-migrated-mandate-may-be-used", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.mandate-fourteen-days-notice-before-a-migrated-mandate-is-created", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.mandate-indemnity-settlement-timeframes-are-not-public", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-participation-is-mandatory-for-a-payer-participant", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.mandate-the-payer-customer-can-view-suspend-cancel-and-amend", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.mandate-the-payer-participant-keeps-processing-pending-word", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.mandate-the-record-is-evidence-of-quantum-frequency-and-beneficiary", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.messages-a-rejected-clearing-request-carries-a-reason-code", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.messages-a-rejected-mandate-payment-request-carries-a-reason-code", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.messages-a-retry-and-a-replay-are-not-the-same-thing", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.messages-iso-20022-from-launch", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.participants-a-connected-institution-cannot-clear", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.participants-a-settlement-participant-need-not-be-an-adi", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.participants-most-institutions-reach-the-platform-through-a-sponsor", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.participants-no-public-list-by-class-exists", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.participants-the-rules-are-a-contract-under-seal", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.participants-three-classes-and-two-capabilities", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.recall-a-duplicate-or-error-payment-return-is-discretionary", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.recall-a-misdirected-payment-is-returned-if-the-payee-participant-is-satisfied", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.recall-a-mistaken-payment-must-be-assessed-and-returned-if-needed", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.recall-a-request-for-payment-return-is-a-request-not-a-right", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.recall-the-payer-participant-carries-its-own-customers-loss", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.recall-the-payer-participant-indemnifies-a-good-faith-return", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.recall-there-is-no-recall-and-no-cancellation-message", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.refund-the-scheme-gives-a-customer-no-refund-right", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.return-a-return-is-a-new-payment-going-the-other-way", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.return-a-zero-value-return-is-forbidden", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.return-an-unsolicited-return-is-the-payee-participants-own-choice", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.return-only-a-cleared-payment-may-be-returned", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.return-windows-and-deadlines-are-not-public", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.settlement-a-clearing-participant-settles-through-another-participant", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.settlement-authorisation-by-the-rba-is-required-to-settle", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.settlement-contingency-and-indeterminate-status-sit-in-the-procedures", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.settlement-per-payment-rtgs-across-exchange-settlement-accounts", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.settlement-the-gateway-generates-a-settlement-request-automatically", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:state.applied-to-the-payee-account", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:state.cleared", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:state.mandate-active", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:state.mandate-awaiting-authorisation", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:state.mandate-cancelled", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:state.mandate-declined", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:state.mandate-suspended", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:state.rejected-at-clearing", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:state.returned", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:state.settled", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:state.submitted-to-the-gateway", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:state.voided-by-settlement-rejection", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:txn.bsct", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:txn.ifti-payment", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:txn.mandate-payment", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:txn.non-value-message", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:txn.npp-payment-return", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:txn.os-payment", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:txn.osko-payment", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "au-npp:src.rba-about-rits", "id": "src.rba-about-rits", "rail": "au-npp", "class": "RuleSource", "name": "Reserve Bank of Australia, About RITS", "summary": "The Reserve Bank's own description of the system it owns and operates, and the authoritative public account of the Fast Settlement Service. It says the Fast Settlement Service is a component of RITS that settles New Payments Platform transactions on a real time gross settlement basis 24 hours a day 7 days a week, that it tests whether the paying account holder has the funds and settles or rejects accordingly, and that it carries no liquidity management features so that processing is faster. It also says RITS is an approved real time gross settlement system under the Payment Systems and Netting Act 1998 and that transactions settled through it are final and irrevocable, and that the legal framework of RITS is the RITS Regulations and the membership agreements.", "publisher": "Reserve Bank of Australia", "url": "https://www.rba.gov.au/payments-and-infrastructure/rits/about.html", "source_class": "authoritative_primary", "kind": "web_page", "edition": "live page, read 2026-09-21", "access": "open", "family": "rba", "consulted_on": "2026-09-21", "relations": [], "basis": { "sources": "The document itself, fetched and read on 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-21 for the au-npp rail. A RuleSource describes one edition of one document; its status stays draft and a watch dates it through consulted_on.", "source_edition": "live page, read 2026-09-21", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "au-npp:role.rba-esa-provider", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:role.rba-fss-operator", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.finality-rtgs-settlement-is-final-under-the-netting-act", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.hours-clearing-and-settlement-run-24-hours-every-day", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.settlement-esa-funds-split-between-fss-and-everything-else", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.settlement-no-liquidity-management-features", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.settlement-per-payment-rtgs-across-exchange-settlement-accounts", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.settlement-the-fss-tests-funds-and-settles-or-rejects", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:state.settled", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:src.scams-prevention-framework-act-2025", "id": "src.scams-prevention-framework-act-2025", "rail": "au-npp", "class": "RuleSource", "name": "Scams Prevention Framework Act 2025 (No. 15, 2025)", "summary": "The Act that inserted Part IVF into the Competition and Consumer Act 2010. It builds a duty framework rather than a reimbursement rule: six principles on regulated entities, civil penalties for breaching them, an internal dispute resolution duty, membership of an authorised external dispute resolution scheme, and a right for a victim to recover loss by court action against an entity whose contravention caused it, apportioned among concurrent wrongdoers. Read as made, not as a current compilation.", "publisher": "Commonwealth of Australia", "url": "https://www.legislation.gov.au/C2025A00015/asmade/2025-02-20/text/original/pdf", "source_class": "authoritative_primary", "kind": "statute", "edition": "as made, assented 20 February 2025", "access": "open", "family": "legislation-gov-au", "consulted_on": "2026-09-21", "relations": [], "basis": { "sources": "The document itself, fetched and read on 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-21 for the au-npp rail. A RuleSource describes one edition of one document; its status stays draft and a watch dates it through consulted_on.", "source_edition": "as made, assented 20 February 2025", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "au-npp:exc.spf-scam-complaint", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:role.spf-regulated-entity", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.consumer-law-external-dispute-resolution-membership-from-2026-09-01", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.consumer-law-internal-dispute-resolution-and-apportionment-guidelines", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.consumer-law-the-six-scams-prevention-framework-principles", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.liability-a-scam-victim-recovers-by-proving-a-contravention", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.liability-australia-has-no-mandatory-scam-reimbursement-rule", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:src.spf-regulated-sectors-designation-2026", "id": "src.spf-regulated-sectors-designation-2026", "rail": "au-npp", "class": "RuleSource", "name": "Competition and Consumer (Scams Prevention Framework, Regulated Sectors) Designation 2026", "summary": "The instrument that switched the Scams Prevention Framework on for banking. It designates covered banking services as a regulated sector, names ASIC as the sector regulator for it, and then turns most of Part IVF off for a period: until before 1 September 2026 only the sector code division and the external dispute resolution authorisation section applied, and from 1 September 2026 until before 31 March 2027 the external dispute resolution membership section applies as well. The rest of Part IVF reaches banking from 31 March 2027.", "publisher": "Assistant Treasurer and Minister for Financial Services", "url": "https://www.legislation.gov.au/F2026L00627/asmade/2026-05-28/text/original/pdf", "source_class": "authoritative_primary", "kind": "legislative_instrument", "edition": "F2026L00627, made 22 May 2026, registered 28 May 2026", "access": "open", "family": "legislation-gov-au", "consulted_on": "2026-09-21", "relations": [], "basis": { "sources": "The document itself, fetched and read on 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-21 for the au-npp rail. A RuleSource describes one edition of one document; its status stays draft and a watch dates it through consulted_on.", "source_edition": "F2026L00627, made 22 May 2026, registered 28 May 2026", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "au-npp:exc.spf-scam-complaint", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:role.afca", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:role.asic", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:role.spf-regulated-entity", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.consumer-law-external-dispute-resolution-membership-from-2026-09-01", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.consumer-law-the-rest-of-part-ivf-reaches-banking-on-2027-03-31", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "au-npp:rule.consumer-law-the-six-scams-prevention-framework-principles", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "au-npp:state.applied-to-the-payee-account", "id": "state.applied-to-the-payee-account", "rail": "au-npp", "class": "LifecycleState", "name": "Applied to the payee's account", "summary": "The receiving institution has put the payment on its customer's account. Above a minimum in the procedures, when it does this and how it tells the customer are its own service standards rather than scheme obligations, which is why the near instant experience people expect is a commercial norm on this rail and not a published rule.", "terminal": false, "money_moved": "yes", "visible_as": "the money is on the statement and available", "relations": [ { "type": "precedes", "to": "au-npp:state.returned", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.settlement-per-payment-rtgs-across-exchange-settlement-accounts", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.hours-service-availability-targets-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 6.3(b) and 6.2(f)(i)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links, read 2026-09-21. The settlement finality line also rests on the Reserve Bank's About RITS page, read the same day.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 6.3(b) confirms the Payee Participant may set its own service level standards for applying Cleared BSCTs to accounts beyond the NPP Procedures minimum, and Regulation 6.2(f)(i) confirms nothing obliges it to do so before settlement." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:state.settled", "type": "precedes", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:state.cleared", "id": "state.cleared", "rail": "au-npp", "class": "LifecycleState", "name": "Cleared", "summary": "The receiving institution accepted the clearing request and the paying institution has the notification that says so. Cleared is not settled and it is not final: nothing obliges the receiving institution to put the money on an account yet, and the payment can still be destroyed outright if the settlement service rejects it. This is the state on this rail that has no counterpart on a deferred net settlement rail, because here the two moments are seconds apart and can still come out differently.", "terminal": false, "money_moved": "no", "visible_as": "the payee's app may already show the money, because most institutions credit immediately, but the scheme does not require it", "relations": [ { "type": "precedes", "to": "au-npp:state.settled", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "precedes", "to": "au-npp:state.voided-by-settlement-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.finality-cleared-means-the-payee-participant-accepted-it", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.settlement-the-gateway-generates-a-settlement-request-automatically", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.finality-a-cleared-payment-the-fss-rejects-is-void", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 6.2(b), 6.2(c) and 6.2(f)(i)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links, read 2026-09-21. The settlement finality line also rests on the Reserve Bank's About RITS page, read the same day.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulations 6.2(b) and (c) confirm a payment is cleared at the point the Payer Participant receives an accepting Clearing Notification, which automatically triggers the gateway's Settlement Request, and Regulation 6.2(f)(i) confirms clearing is a state of the message exchange rather than of the account." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:state.submitted-to-the-gateway", "type": "precedes", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:state.mandate-active", "id": "state.mandate-active", "rail": "au-npp", "class": "LifecycleState", "name": "PayTo agreement: active", "summary": "The payer's institution has recorded in the Mandate Management Service that the payer authorised the agreement, or the agreement is a migrated direct debit mandate, which the rulebook treats as active from creation. Only now may the business's side send payment initiation requests, and each must fit the agreement's terms. A change of amount or frequency comes from the business as an updated agreement for the payer to authorise again; the payer may pause or cancel it from their online banking.", "terminal": false, "money_moved": "no", "visible_as": "MMS mandate status Active, the name the NPP Regulations give it", "relations": [ { "type": "precedes", "to": "au-npp:state.mandate-suspended", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "precedes", "to": "au-npp:state.mandate-cancelled", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.mandate-a-request-may-not-be-sent-unless-the-mandate-is-active", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.mandate-authorisation-is-delivered-in-near-real-time", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.mandate-a-migrated-mandate-is-created-without-a-consent-step", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.mandate-an-amount-or-frequency-change-comes-from-the-business", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "definition of Active in 1.1; Regulations 17.4(b), 17.6(c)(v) and (vii), and 17.8(b)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.npp-payto-service-overview-v2", "section": "pages 7 and 8", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.auspayplus-payto-faqs", "section": "can I change, pause, resume or cancel my PayTo agreement", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0, the definition of Active in 1.1 and Regulations 17.4(b), 17.6(c) and 17.8(b); PayTo Service Overview v2.0 pages 7 and 8; the AP+ PayTo FAQs, managing agreements. All read 2026-09-23. Active is a defined status recorded in the MMS, so it is the one state here whose name the rulebook gives. The Overview says some amendments need fresh authorisation; whether the record leaves Active while an amendment waits for the payer is not said in any source read, so no amendment state is drafted.", "confidence": "medium" }, "currency": { "effective_since": "2020-12-02", "effective_to": null, "effective_note": "Drafted 2026-09-23 by the product view slice 3 drafting session from the documents named in basis, each opened and read that day. The date is the drafting note on the Regulations' definition of Active.", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version; PayTo Service Overview v2.0, November 2021; AP+ PayTo FAQs, live page read 2026-09-23. The current edition, NPP Product Rules v.31 of September 2026, has no text layer and was not read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms the definition of Active as the MMS status recorded once the Payer Participant has confirmed the Payer Customer authorised the Mandate, that a Migrated DDR Mandate is deemed Active immediately on creation with no separate consent step, that no Mandate Payment Initiation Request may be sent unless the associated Mandate is Active, that such a request must be consistent with the terms of the Mandate, and that a Payer Participant must give the Payer Customer a facility to instruct Suspend, Cancel or Permitted Amendments. Does not itself state that an amount or frequency change must come from the business as a fresh agreement." }, { "source": "au-npp:src.auspayplus-payto-faqs", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms that a change to the payment amount or frequency must come from the business, which sends an updated PayTo agreement for the payer to authorise afresh, and that a payer may pause, resume or cancel an agreement in their online banking." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:state.mandate-awaiting-authorisation", "type": "precedes", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:state.mandate-suspended", "type": "precedes", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:state.mandate-awaiting-authorisation", "id": "state.mandate-awaiting-authorisation", "rail": "au-npp", "class": "LifecycleState", "name": "PayTo agreement: created, awaiting the payer's authorisation", "summary": "The business's sponsor has created the agreement record in the Mandate Management Service, and the payer has not yet said yes or no. The operator's database has sent an authorisation request to the payer's institution, which must match it to the payer by account number and put it in front of them in near real time; no payment may be requested under it yet. A migrated direct debit mandate never passes through this state, because it is active from the moment it is created.", "terminal": false, "money_moved": "no", "visible_as": null, "relations": [ { "type": "precedes", "to": "au-npp:state.mandate-active", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "precedes", "to": "au-npp:state.mandate-declined", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.mandate-a-mandate-is-a-record-in-the-scheme-operators-database", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.mandate-authorisation-is-delivered-in-near-real-time", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.mandate-a-request-may-not-be-sent-unless-the-mandate-is-active", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 17.6(c)(i) to (v), 17.6(c)(viii) and 17.8(b), and the definition of Active in 1.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.npp-payto-service-overview-v2", "section": "page 7 and the worked examples on pages 18 to 21", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 Regulation 17.6(c) and the definition of Active, and the PayTo Service Overview v2.0 pages 7 and 18 to 21, read 2026-09-23. The Regulations describe the step (an authorisation request delivered to the payer, and a confirmation recorded after the payer authorises or rejects) but give no name or status value for a mandate waiting at it; the Overview's worked examples describe the payer's bank being told a new agreement has been created and needs the payer's authorisation. So visible_as is null: no public source read gives the MMS status value. The Regulations read are v21.0; the current edition, v.31, has no text layer.", "confidence": "medium" }, "currency": { "effective_since": "2020-12-02", "effective_to": null, "effective_note": "Drafted 2026-09-23 by the product view slice 3 drafting session from the documents named in basis, each opened and read that day. The date is the drafting note on the Regulations' definition of Active, which is what this state leads to, as on the Authorised Payment Mandate; the Regulations date individual amendments, not Part 17 as a whole [Inference].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version; PayTo Service Overview v2.0, November 2021. The current edition, NPP Product Rules v.31 of September 2026, has no text layer and was not read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms that a Payer Participant must receive Mandate Authorisation Requests from the MMS, associate the request with a Payer Customer by account number, deliver it to the Payer Customer in near real time for authorisation, and record a Mandate Authorisation Confirmation in the MMS after the Payer Customer authorises or rejects it, and that no Mandate Payment Initiation Request may be sent unless the Mandate is Active. Confirms a Migrated DDR Mandate is deemed Active on creation, so it never passes through this waiting step." }, { "source": "au-npp:src.npp-payto-service-overview-v2", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "The worked examples show the creditor's or payment initiator's sponsoring institution creating the PayTo agreement in the MMS, and the payer's bank then receiving a notification that a new agreement has been created and needs the payer's authorisation before it is authorised in the payer's banking app." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:state.mandate-cancelled", "id": "state.mandate-cancelled", "rail": "au-npp", "class": "LifecycleState", "name": "PayTo agreement: cancelled", "summary": "The agreement has been ended, by the payer through their institution or by the side that is permitted to under its terms. It can never again carry a payment request, and a payment procured under it after cancellation counts as unauthorised for a Mandate Claim. The record stays in the operator's database for investigations. Cancelling ends the authorisation, not the payer's contract with the business.", "terminal": true, "money_moved": "no", "visible_as": null, "relations": [ { "type": "governed_by", "to": "au-npp:rule.mandate-the-payer-customer-can-view-suspend-cancel-and-amend", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.mandate-a-request-may-not-be-sent-unless-the-mandate-is-active", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 17.6(c)(vii) and (d), 17.7(b)(iv) and 17.10(c)(i)(B)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.npp-payto-service-overview-v2", "section": "page 8", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.auspayplus-payto-faqs", "section": "can I change, pause, resume or cancel my PayTo agreement", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 Regulations 17.6(c)(vii) and (d), 17.7(b) and 17.10(c)(i)(B); PayTo Service Overview v2.0 page 8; AP+ PayTo FAQs. All read 2026-09-23. The Regulations name the operation (Cancel) and treat a cancelled mandate as one no request may use; the Overview says a cancelled agreement cannot be used again. No public source read gives the MMS status value, so visible_as is null. That the record is kept for investigations is [Inference] from 17.7(b)(iv), which preserves access to historic Mandate data for investigations.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-23 by the product view slice 3 drafting session from the documents named in basis, each opened and read that day.", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version; PayTo Service Overview v2.0, November 2021; AP+ PayTo FAQs, live page read 2026-09-23. The current edition, NPP Product Rules v.31 of September 2026, has no text layer and was not read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms the Payer Participant must give the Payer Customer a facility to instruct Cancel and promptly give effect to it, that no Mandate Payment Initiation Request may be sent unless the Mandate is Active, that a Mandate Payment procured while the Mandate is cancelled counts as not authorised for a Mandate Claim, and that a party's right to access historic Mandate data for investigations survives Porting rights." }, { "source": "au-npp:src.npp-payto-service-overview-v2", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms that once cancelled a PayTo agreement cannot be used to initiate any further payments, and that cancelling an agreement does not change any contractual arrangement between the payer customer and the third party." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:state.mandate-active", "type": "precedes", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:state.mandate-suspended", "type": "precedes", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:state.mandate-declined", "id": "state.mandate-declined", "rail": "au-npp", "class": "LifecycleState", "name": "PayTo agreement: declined by the payer", "summary": "The payer was shown the agreement and refused it, and their institution recorded the refusal in the Mandate Management Service. The agreement never became active and no payment may be requested under it. If the terms were wrong, the business has to create a fresh agreement for the payer to authorise.", "terminal": true, "money_moved": "no", "visible_as": null, "relations": [ { "type": "governed_by", "to": "au-npp:rule.mandate-authorisation-is-delivered-in-near-real-time", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.mandate-a-request-may-not-be-sent-unless-the-mandate-is-active", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 17.6(c)(v) and 17.8(b)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.auspayplus-payto-faqs", "section": "what if the details of the PayTo agreement are wrong", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 Regulation 17.6(c)(v), under which the payer's institution records a confirmation after the payer authorises or rejects, and 17.8(b); AP+ PayTo FAQs, where a payer who does not want to proceed declines and the business creates a new agreement. Both read 2026-09-23. Neither gives an MMS status value, so visible_as is null. That the refused record is terminal rather than reusable is [Inference] from the FAQ's direction that the business creates a new agreement.", "confidence": "low" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-23 by the product view slice 3 drafting session from the documents named in basis, each opened and read that day.", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version; AP+ PayTo FAQs, live page read 2026-09-23. The current edition, NPP Product Rules v.31 of September 2026, has no text layer and was not read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms the Payer Participant records a Mandate Authorisation Confirmation in the MMS following the Payer Customer's authorisation or rejection, and that no Mandate Payment Initiation Request may be sent unless the Mandate is Active." }, { "source": "au-npp:src.auspayplus-payto-faqs", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms that a payer who sees a PayTo agreement with wrong details can decline it and contact the business, which can then create a new agreement for the payer to authorise." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:state.mandate-awaiting-authorisation", "type": "precedes", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:state.mandate-suspended", "id": "state.mandate-suspended", "rail": "au-npp", "class": "LifecycleState", "name": "PayTo agreement: suspended (paused)", "summary": "The agreement has been put on hold, most often by the payer through their institution's online banking, where it is called pausing. While it is suspended no payment may be requested under it, and a payment procured anyway counts as unauthorised for a Mandate Claim. It can be made active again, and the operator's overview says only the party that paused it can do that. Pausing leaves the payer's contract with the business untouched.", "terminal": false, "money_moved": "no", "visible_as": "shown to the payer as paused in their online banking (AP+ FAQs and the PayTo Service Overview); the Regulations' word is Suspend", "relations": [ { "type": "precedes", "to": "au-npp:state.mandate-active", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "precedes", "to": "au-npp:state.mandate-cancelled", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.mandate-the-payer-customer-can-view-suspend-cancel-and-amend", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.mandate-a-request-may-not-be-sent-unless-the-mandate-is-active", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 17.4(d)(iii), 17.6(c)(vii) and (d), and 17.10(c)(i)(B)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.npp-payto-service-overview-v2", "section": "pages 5, 8 and 10", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.auspayplus-payto-faqs", "section": "can I change, pause, resume or cancel my PayTo agreement", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 Regulations 17.4(d)(iii), 17.6(c)(vii) and (d), and 17.10(c)(i)(B); PayTo Service Overview v2.0 pages 5, 8 and 10; AP+ PayTo FAQs. All read 2026-09-23. The Regulations name the operation (Suspend) and the condition (a mandate suspended when a request was sent) but give no MMS status value; the customer word is pause. That only the party that paused it can reactivate it is from the 2021 Overview alone and is not in the Regulations read. That the business side can also suspend is not stated in any source read and is not claimed.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-23 by the product view slice 3 drafting session from the documents named in basis, each opened and read that day.", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version; PayTo Service Overview v2.0, November 2021; AP+ PayTo FAQs, live page read 2026-09-23. The current edition, NPP Product Rules v.31 of September 2026, has no text layer and was not read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms the Payer Participant must give the Payer Customer a facility to instruct Suspend and promptly give effect to it, that no Mandate Payment Initiation Request may be sent unless the Mandate is Active, and that a Mandate Payment procured while the Mandate is suspended counts as not authorised for a Mandate Claim." }, { "source": "au-npp:src.npp-payto-service-overview-v2", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms that a paused PayTo agreement can be activated again only by the party who paused it, and that customers can view PayTo agreements and give instructions in their banking app. The AP+ PayTo FAQs, already recorded on this rail, separately confirm pausing does not change the contract with the business." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:state.mandate-active", "type": "precedes", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:state.rejected-at-clearing", "id": "state.rejected-at-clearing", "rail": "au-npp", "class": "LifecycleState", "name": "Rejected by the payee participant", "summary": "The receiving institution answered the clearing request with a rejection inside the configured timeout and put a reason code in the message. No money moved, there is nothing to return, and the payment simply does not exist. The values a reason code may take on this leg are in the procedures and are not public.", "terminal": true, "money_moved": "no", "visible_as": "the payer's app shows the payment as failed, with whatever wording the sending institution chooses", "relations": [ { "type": "governed_by", "to": "au-npp:rule.messages-a-rejected-clearing-request-carries-a-reason-code", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.hours-response-timeout-values-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 6.3(a)(ii)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links, read 2026-09-21. The settlement finality line also rests on the Reserve Bank's About RITS page, read the same day.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 6.3(a)(ii) confirms a Payee Participant rejects a Clearing Request by initiating a Clearing Notification indicating rejection with a valid and applicable Reason Code." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:exc.clearing-rejection", "type": "enters", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:state.submitted-to-the-gateway", "type": "precedes", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:state.returned", "id": "state.returned", "rail": "au-npp", "class": "LifecycleState", "name": "Returned", "summary": "The receiving institution has sent the money back, either because the paying institution asked or on its own initiative. What travelled is a fresh payment in the opposite direction, so the original payment is still settled and still final; the ledger now holds two payments rather than none. Whether the payer's customer gets the money is a separate question from whether it reached the payer's institution.", "terminal": true, "money_moved": "yes", "visible_as": "the payer sees a credit arriving rather than the original payment disappearing", "relations": [ { "type": "governed_by", "to": "au-npp:rule.return-a-return-is-a-new-payment-going-the-other-way", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.return-only-a-cleared-payment-may-be-returned", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.return-windows-and-deadlines-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 6.5, 6.6 and the definition of NPP Payment Return", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links, read 2026-09-21. The settlement finality line also rests on the Reserve Bank's About RITS page, read the same day.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulations 6.5 and 6.6 and the definition of NPP Payment Return confirm a returned payment is one for which the Payee Participant has sent a pacs.004 NPP Payment Return, whether unsolicited or requested, and that the original payment stays settled." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:exc.duplicate-or-error-payment-return-request", "type": "enters", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:exc.mandate-claim", "type": "enters", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:exc.misdirected-payment-return-request", "type": "enters", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:exc.mistaken-payment-return-request", "type": "enters", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:exc.unsolicited-return", "type": "enters", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:state.applied-to-the-payee-account", "type": "precedes", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:state.settled", "type": "precedes", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:state.settled", "id": "state.settled", "rail": "au-npp", "class": "LifecycleState", "name": "Settled in the Fast Settlement Service", "summary": "Value has moved between the two institutions' exchange settlement accounts at the Reserve Bank, individually and in central bank money, and both sides have the notification that says so. This is the moment the payment becomes irrevocable, and settlement through the system it runs in is final and irrevocable as a matter of statute. Money coming back after this point is a new payment, never an undoing of this one.", "terminal": false, "money_moved": "yes", "visible_as": "the payee's app shows the money, if it did not already", "relations": [ { "type": "precedes", "to": "au-npp:state.applied-to-the-payee-account", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "precedes", "to": "au-npp:state.returned", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.finality-irrevocable-on-settlement-in-the-fss", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.finality-rtgs-settlement-is-final-under-the-netting-act", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.settlement-per-payment-rtgs-across-exchange-settlement-accounts", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 6.2(d), 7.3 and 7.4(a)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.rba-about-rits", "section": "Real-time Gross Settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links, read 2026-09-21. The settlement finality line also rests on the Reserve Bank's About RITS page, read the same day.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulations 6.2(d), 7.3 and 7.4(a) confirm a Cleared payment is irrevocable once settled by the FSS, with settlement effected by exchange of value across ESAs and confirmed by a Settlement Notification." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:state.cleared", "type": "precedes", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:state.submitted-to-the-gateway", "id": "state.submitted-to-the-gateway", "rail": "au-npp", "class": "LifecycleState", "name": "Submitted to the payer participant's gateway", "summary": "The clearing request has been put into the paying institution's own gateway. This is the moment the payer participant loses the ability to cancel or recall it, and it comes before anything the receiving side or the settlement service does. Nothing has moved and the payee knows nothing about it.", "terminal": false, "money_moved": "no", "visible_as": "the payer's app usually shows the payment as sent", "relations": [ { "type": "precedes", "to": "au-npp:state.cleared", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "precedes", "to": "au-npp:state.rejected-at-clearing", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.finality-no-cancel-or-recall-once-the-message-is-in-the-gateway", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-iso-20022-from-launch", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 6.2(a)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links, read 2026-09-21. The settlement finality line also rests on the Reserve Bank's About RITS page, read the same day.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 6.2(a) confirms the point at which a Clearing Request is input into the Payer Participant's own gateway is the point past which it may not be cancelled or recalled." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:state.voided-by-settlement-rejection", "id": "state.voided-by-settlement-rejection", "rail": "au-npp", "class": "LifecycleState", "name": "Void, because the settlement service rejected it", "summary": "The settlement service tested the paying institution's funds, rejected the settlement request, and the payment that had already been cleared is deemed immediately void. The paying institution owes the receiving institution and the payee nothing for it, and it alone decides whether to send the same message again or send it marked as a retry. What the receiving institution does about a credit it may already have given its customer is not something the public rules answer.", "terminal": true, "money_moved": "no", "visible_as": "usually nothing at all, unless the receiving institution had already credited the account and takes it back", "relations": [ { "type": "governed_by", "to": "au-npp:rule.finality-a-cleared-payment-the-fss-rejects-is-void", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.finality-the-payer-participant-alone-decides-to-replay-or-retry", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.settlement-the-fss-tests-funds-and-settles-or-rejects", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 6.2(e), 6.2(f)(ii) and 7.4(b)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024, at the regulations named in the record's links, read 2026-09-21. The settlement finality line also rests on the Reserve Bank's About RITS page, read the same day.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulations 6.2(e) and 6.2(f)(ii) confirm a Cleared payment the FSS rejects is deemed immediately void with no liability on the Payer Participant, and Regulation 7.4(b) confirms rejection of a Settlement Request automatically voids the associated Cleared payment." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:exc.settlement-rejection", "type": "enters", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:state.cleared", "type": "precedes", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:txn.bsct", "id": "txn.bsct", "rail": "au-npp", "class": "TransactionType", "name": "Basic Single Credit Transfer (BSCT)", "summary": "The ordinary NPP payment: a credit payment message that is neither an overlay service payment nor the domestic leg of an international transfer, sent by one participant for the benefit of a payee at another participant or at an identified institution. It must be in Australian dollars, between Australian domiciled accounts, and it must carry a transaction identifier. A zero value one may not be sent and the receiving participant is obliged to reject it. An on us payment inside one institution is outside the definition.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "the definition of Basic Single Credit Transfer, and Regulations 6.1(b) and 6.1(c)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024 at the definitions and regulations named in the record's links, and the NPP Payment Initiation Messages guidance v4.0. Both read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "The definition of Basic Single Credit Transfer confirms it as a credit payment message, other than an OS Payment or an IFTI Payment, sent between NPP Participants or Identified Institutions, and Regulations 6.1(b) and (c) confirm it must be in AUD, between Australian domiciled accounts, correctly formatted, and never zero value." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.finality-a-cleared-payment-the-fss-rejects-is-void", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.finality-cleared-means-the-payee-participant-accepted-it", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.finality-irrevocable-on-settlement-in-the-fss", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.finality-no-cancel-or-recall-once-the-message-is-in-the-gateway", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.limits-a-zero-value-payment-is-forbidden", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.limits-the-scheme-sets-no-maximum-value", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.messages-iso-20022-from-launch", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.settlement-per-payment-rtgs-across-exchange-settlement-accounts", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:txn.ifti-payment", "id": "txn.ifti-payment", "rail": "au-npp", "class": "TransactionType", "name": "IFTI Payment", "summary": "The domestic leg of an international funds transfer instruction, sent to another participant that may be the beneficiary institution or an intermediary in the chain. It must carry the international transfer code in the clearing request header, and the rulebook says plainly that a participant must not send an uncoded ordinary or overlay payment for one.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulation 6.1(b)(vi) and its note, and the definition of IFTI Payment", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024 at the definitions and regulations named in the record's links, and the NPP Payment Initiation Messages guidance v4.0. Both read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 6.1(b)(vi) and its note confirm an IFTI Payment must carry the IFTI code in the Clearing Request header and follow the IFTI Payments business service rules, and the definition of IFTI Payment confirms it as an NPP Payment relating to an international funds transfer instruction." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp:txn.mandate-payment", "id": "txn.mandate-payment", "rail": "au-npp", "class": "TransactionType", "name": "Mandate Payment (PayTo)", "summary": "A payment the payer's own institution makes on the strength of an active mandate held in the Mandate Management Service, after an initiating participant sends it a mandate payment initiation request. Nothing is pulled: this is an ordinary credit push that a stored authorisation set going, which is why the rulebook calls it a persistently authorised debit-like credit transfer.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "the Part 17 preamble and Regulations 17.1(b) and (c), and 17.8(b)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024 at the definitions and regulations named in the record's links, and the NPP Payment Initiation Messages guidance v4.0. Both read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "The Part 17 preamble and Regulation 17.1(b) and (c) confirm a Mandate Payment is an NPP Payment initiated under a Mandate Payment Initiation Request carrying a Mandate ID, and Regulation 17.8(b) confirms the Payer Participant answers it with a status report and, if accepted, a Clearing Request." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:mandate.authorised-payment-mandate", "type": "authorises", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:mandate.debtor-payment-arrangement", "type": "authorises", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:mandate.migrated-ddr-mandate", "type": "authorises", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.finality-no-cancel-or-recall-once-the-message-is-in-the-gateway", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-a-mandate-is-a-record-in-the-scheme-operators-database", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-a-migrated-mandate-is-created-without-a-consent-step", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-a-request-may-not-be-sent-unless-the-mandate-is-active", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.mandate-five-days-before-a-migrated-mandate-may-be-used", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.messages-a-rejected-mandate-payment-request-carries-a-reason-code", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.messages-iso-20022-from-launch", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AG01", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM06", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM09", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM21", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:MD01", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:NAUT", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:txn.non-value-message", "id": "txn.non-value-message", "rail": "au-npp", "class": "TransactionType", "name": "Non-Value Message", "summary": "A message that carries no money, such as a payment initiation request or an enquiry. It is the only traffic a connected institution has a right to send, and the sanctions and know your customer obligations that apply to payments apply to these as well.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": false, "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "the definition of Non-Value Message, and Regulations 4.1(b)(ii) and 6.1(d)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024 at the definitions and regulations named in the record's links, and the NPP Payment Initiation Messages guidance v4.0. Both read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "The definition of Non-Value Message and Regulation 4.1(b)(ii) confirm Connected Institutions are entitled to send and receive Non-Value Messages, and Regulation 6.1(d) confirms the sanctions and AML/CTF compliance framework applies to NPP Payments and Non-Value Messages alike." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.participants-a-connected-institution-cannot-clear", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:txn.npp-payment-return", "id": "txn.npp-payment-return", "rail": "au-npp", "class": "TransactionType", "name": "NPP Payment Return", "summary": "The message a receiving participant sends to give a settled payment back, either on its own initiative or because the paying participant asked. It is a new payment going the other way rather than a reversal of the first one, and a zero value one may not be sent.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "the definition of NPP Payment Return, and Regulations 6.1(c)(ii), 6.5 and 6.6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024 at the definitions and regulations named in the record's links, and the NPP Payment Initiation Messages guidance v4.0. Both read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "The definition of NPP Payment Return confirms it as the pacs.004 message a Payee Participant sends to effect a return, and Regulations 6.1(c)(ii), 6.5 and 6.6 confirm it may never carry a zero value and is the only route back for a settled payment." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.limits-a-zero-value-payment-is-forbidden", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.return-a-return-is-a-new-payment-going-the-other-way", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.return-a-zero-value-return-is-forbidden", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.return-only-a-cleared-payment-may-be-returned", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:txn.os-payment", "id": "txn.os-payment", "rail": "au-npp", "class": "TransactionType", "name": "Overlay Service Payment (OS Payment)", "summary": "A payment sent under the rules of an approved overlay service, which must carry that service's identifier in the clearing request header. Overlay rules may add requirements on top of the core clearing and settlement rules but may not contradict them.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "Regulations 6.1(b)(v) and 17.3(b), and the definition of OS Payment", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024 at the definitions and regulations named in the record's links, and the NPP Payment Initiation Messages guidance v4.0. Both read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "Regulation 6.1(b)(v) confirms an OS Payment must include the applicable Overlay Service Identifier in its Clearing Request header, Regulation 17.3(b) confirms an Overlay Service Mandate Payment Initiation Request must include that identifier too, and the definition of OS Payment confirms it as a payment processed under an approved Overlay Service's rules." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.finality-no-cancel-or-recall-once-the-message-is-in-the-gateway", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:txn.osko-payment", "id": "txn.osko-payment", "rail": "au-npp", "class": "TransactionType", "name": "Osko Payment", "summary": "A payment instruction an Osko participant processes as a basic single credit transfer through the infrastructure. Osko is universally described as the platform's first overlay service, and yet the rulebook defines an ordinary payment as one that is not an overlay payment and then defines an Osko payment as one processed as an ordinary payment. Orca records both readings and asserts neither.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-regulations-v21", "section": "the definitions of Osko Payment, Basic Single Credit Transfer and OS Payment, and Regulation 6.11", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024 at the definitions and regulations named in the record's links, and the NPP Payment Initiation Messages guidance v4.0. Both read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-regulations-v21", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "The definitions of Osko Payment, Basic Single Credit Transfer and OS Payment and Regulation 6.11 confirm the genuine ambiguity: Basic Single Credit Transfer excludes an OS Payment by definition, and Osko Payment is defined as a Payment Instruction processed as a Basic Single Credit Transfer, so on the Regulations' own wording an Osko Payment is not an OS Payment even though Osko is described elsewhere as the first overlay service." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.limits-participants-set-their-own-customer-limits", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp:txn.payment-initiation-instruction", "id": "txn.payment-initiation-instruction", "rail": "au-npp", "class": "TransactionType", "name": "Payment initiation instruction (pain.001)", "summary": "The instruction a corporate or government customer sends its own institution asking it to make one or more NPP payments, and the status report the institution sends back. It moves no money itself: the institution builds a clearing request from it. Whether an institution accepts these messages at all, and what it puts in the status report, is that institution's own commercial matter and not something the scheme requires.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": false, "relations": [ { "type": "sourced_from", "to": "au-npp:src.npp-payment-initiation-messages-v4", "section": "Background, and the pain.001 and pain.002 guidance tables", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPP Regulations v21.0 of 24 September 2024 at the definitions and regulations named in the record's links, and the NPP Payment Initiation Messages guidance v4.0. Both read 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the Regulations date individual amendments, not the provision as a whole", "effective_to": null, "effective_note": "Drafted 2026-09-21 from the NPP Regulations v21.0 of 24 September 2024, the newest edition of the governing rulebook an agent can read. NPPA publishes the current edition, NPP Product Rules v.31 of September 2026, as 102 scanned page images carrying no text layer, so what moved between the two editions is not held [Unverified].", "source_edition": "NPP Regulations v21.0, 24 September 2024, public redacted version, read 2026-09-21. The current edition, NPP Product Rules v.31 of September 2026, was downloaded on 2026-09-21 and could not be read: 102 pages, no font resource on any page, and no character extractable. Regulation 6.9 and Annexure C are redacted in the edition that was read.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "au-npp:src.npp-payment-initiation-messages-v4", "checked_on": "2026-09-21", "checked_by": "au-npp-validator-2026-09-21", "notes": "The Background section and the pain.001 and pain.002 guidance confirm a payment initiation instruction is the message format corporate, government and third party customers may use to submit payment instructions to their own NPP FI, answered by a pain.002 status report, on a leg the FI's acceptance and provision of is proprietary and at its discretion." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.messages-four-status-code-values-on-the-initiation-leg", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC02", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC03", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC05", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC06", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC07", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC13", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC14", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC15", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AG01", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AG03", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AGNT", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM01", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM02", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM03", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM04", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM06", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM09", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM12", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM19", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM21", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:BE06", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:BE08", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:BE22", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:CH20", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:CH21", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:CURR", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:DT02", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:DT04", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:FF10", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:MD01", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:NARR", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:NAUT", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:TD03", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "au-npp:rule.consumer-law-the-epayments-code-is-voluntary", "au-npp:rule.consumer-law-afca-hears-a-mistaken-payment-complaint", "au-npp:rule.consumer-law-the-six-scams-prevention-framework-principles", "au-npp:rule.consumer-law-internal-dispute-resolution-and-apportionment-guidelines", "au-npp:rule.consumer-law-external-dispute-resolution-membership-from-2026-09-01", "au-npp:rule.consumer-law-the-rest-of-part-ivf-reaches-banking-on-2027-03-31" ], "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.", "relations": [ { "type": "see_also", "to": "uk-fps:consumer-law", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "in-upi:consumer-law", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp:src.scams-prevention-framework-act-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": "au-npp:src.spf-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": "au-npp:src.epayments-code-2022", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.refund-the-scheme-gives-a-customer-no-refund-right", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:liability", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:refund", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "au-npp:rule.decision-points-the-payee-participant-accepts-or-rejects", "au-npp:rule.decision-points-the-payer-participant-screens-before-it-sends", "au-npp:rule.decision-points-the-payer-acts-on-a-confirmation-of-payee-outcome", "au-npp:rule.mandate-a-mandate-is-a-record-in-the-scheme-operators-database", "au-npp:rule.mandate-participation-is-mandatory-for-a-payer-participant", "au-npp:rule.mandate-authorisation-is-delivered-in-near-real-time", "au-npp:rule.mandate-a-request-may-not-be-sent-unless-the-mandate-is-active", "au-npp:rule.decision-points-the-payer-customer-authorises-pauses-or-cancels-a-mandate", "au-npp:rule.mandate-the-payer-customer-can-view-suspend-cancel-and-amend", "au-npp:rule.mandate-an-amount-or-frequency-change-comes-from-the-business", "au-npp:rule.mandate-a-mandate-may-be-ported-to-another-participant", "au-npp:rule.mandate-data-is-confidential-to-the-parties", "au-npp:rule.mandate-the-record-is-evidence-of-quantum-frequency-and-beneficiary", "au-npp:rule.mandate-a-migrated-mandate-is-created-without-a-consent-step", "au-npp:rule.mandate-fourteen-days-notice-before-a-migrated-mandate-is-created", "au-npp:rule.mandate-five-days-before-a-migrated-mandate-may-be-used", "au-npp:rule.decision-points-the-payer-participant-may-seek-confirmation-of-a-migrated-mandate", "au-npp:rule.mandate-the-payer-participant-keeps-processing-pending-word", "au-npp:rule.recall-a-duplicate-or-error-payment-return-is-discretionary", "au-npp:rule.refund-where-the-funds-are-short-the-receiving-adi-weighs-the-two-customers" ], "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.", "relations": [ { "type": "see_also", "to": "uk-fps:decision-points", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp:decision-points", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp:src.npp-regulations-v21", "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": "au-npp:src.epayments-code-2022", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "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.", "rules": [ "au-npp:rule.finality-no-cancel-or-recall-once-the-message-is-in-the-gateway", "au-npp:rule.finality-cleared-means-the-payee-participant-accepted-it", "au-npp:rule.finality-irrevocable-on-settlement-in-the-fss", "au-npp:rule.finality-a-cleared-payment-the-fss-rejects-is-void", "au-npp:rule.finality-the-payer-participant-alone-decides-to-replay-or-retry", "au-npp:rule.finality-rtgs-settlement-is-final-under-the-netting-act" ], "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.", "relations": [ { "type": "see_also", "to": "rtp:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "fednow:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "ch-sic-ip:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp:src.npp-regulations-v21", "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": "au-npp:src.rba-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:settlement", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "au-npp:rule.hours-clearing-and-settlement-run-24-hours-every-day", "au-npp:rule.hours-response-timeout-values-are-not-public", "au-npp:rule.hours-service-availability-targets-are-not-public" ], "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.", "relations": [ { "type": "see_also", "to": "rtp:hours", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "fednow:hours", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:hours", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp:src.npp-regulations-v21", "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": "au-npp:src.rba-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "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.", "rules": [ "au-npp:rule.liability-the-initiating-participant-indemnifies-against-mandate-claims", "au-npp:rule.liability-a-sponsor-takes-full-risk-on-the-users-it-sponsors", "au-npp:rule.liability-a-registering-participant-indemnifies-a-misdirected-payment", "au-npp:rule.recall-the-payer-participant-carries-its-own-customers-loss", "au-npp:rule.mandate-a-migrated-mandate-claim-is-deemed-substantiated", "au-npp:rule.mandate-an-authorised-mandate-claim-is-deemed-substantiated-by-the-record", "au-npp:rule.mandate-indemnity-settlement-timeframes-are-not-public", "au-npp:rule.liability-the-holder-is-not-liable-where-an-identifier-alone-can-pay", "au-npp:rule.liability-the-holder-is-liable-where-the-subscriber-proves-contribution", "au-npp:rule.liability-the-residual-cap-is-150-dollars", "au-npp:rule.liability-a-deceived-payer-is-not-an-unauthorised-transaction", "au-npp:rule.liability-australia-has-no-mandatory-scam-reimbursement-rule", "au-npp:rule.liability-a-scam-victim-recovers-by-proving-a-contravention" ], "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.", "relations": [ { "type": "see_also", "to": "uk-fps:liability", "note": "The sharpest contrast in the corpus, and the reason to read both: one rail has a mandatory capped split reimbursement duty for authorised scam payments and this one has nothing of the kind.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "in-upi:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:consumer-law", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "au-npp:consumer-law", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:decision-points", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "au-npp:rule.limits-the-scheme-sets-no-maximum-value", "au-npp:rule.limits-a-zero-value-payment-is-forbidden", "au-npp:rule.limits-participants-set-their-own-customer-limits", "au-npp:rule.limits-nppa-may-direct-value-limits-for-capacity" ], "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.", "relations": [ { "type": "see_also", "to": "rtp:limits", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "fednow:limits", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:limits", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "nct-inst:limits", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp:src.npp-regulations-v21", "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)." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "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.", "rules": [ "au-npp:rule.messages-iso-20022-from-launch", "au-npp:rule.messages-a-rejected-clearing-request-carries-a-reason-code", "au-npp:rule.messages-a-rejected-mandate-payment-request-carries-a-reason-code", "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "au-npp:rule.messages-four-status-code-values-on-the-initiation-leg", "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "au-npp:rule.messages-a-retry-and-a-replay-are-not-the-same-thing" ], "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.", "relations": [ { "type": "see_also", "to": "rtp:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "fednow:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct-inst:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp-reject:rail.au-npp-reject", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp:src.npp-regulations-v21", "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": "au-npp:src.npp-payment-initiation-messages-v4", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp-reject:rail.au-npp-reject", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC02", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC03", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC05", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC06", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC07", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC13", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC14", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AC15", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AG01", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AG03", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AGNT", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM01", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM02", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM03", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM04", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM06", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM09", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM12", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM19", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:AM21", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:BE06", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:BE08", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:BE22", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:CH20", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:CH21", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:CURR", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:DT02", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:DT04", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:FF10", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:MD01", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:NARR", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:NAUT", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp-reject:TD03", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "au-npp:rule.participants-three-classes-and-two-capabilities", "au-npp:rule.participants-a-settlement-participant-need-not-be-an-adi", "au-npp:rule.participants-a-connected-institution-cannot-clear", "au-npp:rule.participants-most-institutions-reach-the-platform-through-a-sponsor", "au-npp:rule.participants-the-rules-are-a-contract-under-seal", "au-npp:rule.participants-no-public-list-by-class-exists" ], "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.", "relations": [ { "type": "see_also", "to": "uk-fps:participants", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp:participants", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "fednow:participants", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp:src.npp-regulations-v21", "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))." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "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.", "rules": [ "au-npp:rule.recall-there-is-no-recall-and-no-cancellation-message", "au-npp:rule.recall-a-request-for-payment-return-is-a-request-not-a-right", "au-npp:rule.recall-a-mistaken-payment-must-be-assessed-and-returned-if-needed", "au-npp:rule.recall-a-misdirected-payment-is-returned-if-the-payee-participant-is-satisfied", "au-npp:rule.recall-a-duplicate-or-error-payment-return-is-discretionary", "au-npp:rule.recall-the-payer-participant-indemnifies-a-good-faith-return", "au-npp:rule.recall-the-payer-participant-carries-its-own-customers-loss" ], "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.", "relations": [ { "type": "see_also", "to": "uk-fps:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp:src.npp-regulations-v21", "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))." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:decision-points", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:finality", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:liability", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:refund", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:return", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "au-npp:rule.refund-the-scheme-gives-a-customer-no-refund-right", "au-npp:rule.refund-an-on-screen-warning-is-required-but-not-for-payid", "au-npp:rule.refund-the-sending-adi-must-investigate-and-ask-within-5-business-days", "au-npp:rule.refund-the-receiving-adi-answers-within-5-business-days", "au-npp:rule.refund-reported-within-10-business-days-the-money-comes-back", "au-npp:rule.refund-reported-between-10-business-days-and-7-months", "au-npp:rule.refund-reported-after-7-months-only-with-consent", "au-npp:rule.refund-where-the-funds-are-short-the-receiving-adi-weighs-the-two-customers", "au-npp:rule.refund-the-outcome-in-writing-within-30-business-days" ], "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.", "relations": [ { "type": "see_also", "to": "pix:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sdd-core:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:consumer-law", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp:src.epayments-code-2022", "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": "au-npp:src.npp-regulations-v21", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:consumer-law", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:recall", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:return", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "au-npp:rule.return-a-return-is-a-new-payment-going-the-other-way", "au-npp:rule.return-only-a-cleared-payment-may-be-returned", "au-npp:rule.return-a-zero-value-return-is-forbidden", "au-npp:rule.return-an-unsolicited-return-is-the-payee-participants-own-choice", "au-npp:rule.return-windows-and-deadlines-are-not-public" ], "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.", "relations": [ { "type": "see_also", "to": "uk-fps:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp:src.npp-regulations-v21", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:recall", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "au-npp:rule.settlement-per-payment-rtgs-across-exchange-settlement-accounts", "au-npp:rule.settlement-the-gateway-generates-a-settlement-request-automatically", "au-npp:rule.settlement-the-fss-tests-funds-and-settles-or-rejects", "au-npp:rule.settlement-no-liquidity-management-features", "au-npp:rule.settlement-esa-funds-split-between-fss-and-everything-else", "au-npp:rule.settlement-authorisation-by-the-rba-is-required-to-settle", "au-npp:rule.settlement-a-clearing-participant-settles-through-another-participant", "au-npp:rule.settlement-contingency-and-indeterminate-status-sit-in-the-procedures" ], "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.", "relations": [ { "type": "see_also", "to": "rtp:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "fednow:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "ch-sic-ip:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "in-upi:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp:src.npp-regulations-v21", "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": "au-npp:src.rba-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:finality", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:hours", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp-reject:rail.au-npp-reject", "id": "rail.au-npp-reject", "class": "Rail", "rail": "au-npp-reject", "name": "NPP Payment Initiation Reason Codes (Australia)", "governing_authority": "NPP Australia Limited", "country": "AU", "currency": "AUD", "operators": [ "NPP Australia Limited (scheme operator, a subsidiary of Australian Payments Plus Limited)", "Reserve Bank of Australia (Fast Settlement Service, a component of RITS)" ], "record_label": "Reject Reasons", "brief": "docs/rails/au-npp.md", "scheme": "au-npp:rail.au-npp", "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" ], "relations": [ { "type": "sourced_from", "to": "au-npp-reject:src.npp-payment-initiation-messages-v4", "section": "Appendix F, and the note under it", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:rail.au-npp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "source_class": null, "effective_status_reason": null, "used_by": [ { "from": "au-npp:rail.au-npp", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "au-npp:messages", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp-reject:src.npp-payment-initiation-messages-v4", "id": "src.npp-payment-initiation-messages-v4", "rail": "au-npp-reject", "class": "RuleSource", "name": "NPP Payment Initiation Messages, technical guidance for corporates, government and third parties, v4.0", "summary": "The only code list the governing authority publishes. Appendix F carries 33 reason code values with an ISO name and a description of the error for each, and Appendix E carries 4 status code values. A note under each appendix says an NPP financial institution may offer alternative values, and the background section says an institution's acceptance of customer payment instructions and provision of status reports is proprietary and at its discretion. The document opens with an acceptance block, whose terms are warranty and liability disclaimers and intellectual property notices, and every page footer reads Confidential while the file sits on a public page with a plain download link.", "publisher": "Australian Payments Plus Limited and NPP Australia Limited", "url": "https://www.auspayplus.com.au/wp-content/uploads/2026/03/NPP-payment-initiation-V4.0.pdf", "source_class": "authoritative_primary", "kind": "technical_guidance", "edition": "v4.0, 20 November 2025, uploaded March 2026", "access": "terms", "family": "auspayplus", "consulted_on": "2026-09-21", "relations": [], "basis": { "sources": "The document itself, fetched and read on 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-21 for the au-npp-reject directory. A RuleSource copy stays in the directory that cites it, so au-npp holds its own record of the same document.", "source_edition": "v4.0, 20 November 2025", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "au-npp-reject:rail.au-npp-reject", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "au-npp-reject:src.westpac-bankrec-npp", "id": "src.westpac-bankrec-npp", "rail": "au-npp-reject", "class": "RuleSource", "name": "Westpac BankRec, New Payments Platform (NPP)", "summary": "A participant's own public developer documentation. It carries two tables: eleven NPP transaction codes that appear on a Westpac statement, separating simple credit transfer from Osko across debit, credit, return and reversal, and a list of about fifty NPP return and reversal codes plus four wildcard families for technical issues. Its scope names the NPP. Its meanings agree with the authority's published list on fifteen shared values and disagree on five, and it also carries values the authority's list does not have at all. It is a participant describing a different leg of the payment, and a shared code value may legitimately mean two different things on two different legs.", "publisher": "Westpac Banking Corporation", "url": "https://bankrec.westpac.com.au/docs/npp/", "source_class": "secondary", "kind": "web_page", "edition": "undated live page, read 2026-09-21", "access": "open", "family": "westpac", "consulted_on": "2026-09-21", "relations": [], "basis": { "sources": "The page itself, fetched and read on 2026-09-21.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-21. The page carries no date or version, so a watch must compare its content rather than a date.", "source_edition": "undated live page, read 2026-09-21", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp-reject:AC02", "id": "AC02", "rail": "au-npp-reject", "class": "ReasonCode", "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, "guidance": "A corrected instruction can be sent. Nothing left the institution, so there is nothing to reverse." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "au-npp:txn.payment-initiation-instruction" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "au-npp:exc.payment-initiation-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.payment-initiation-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp-reject:src.npp-payment-initiation-messages-v4", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp-reject:AC03", "id": "AC03", "rail": "au-npp-reject", "class": "ReasonCode", "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, "guidance": "Send a corrected instruction once the payee's details are confirmed." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "au-npp:txn.payment-initiation-instruction" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "au-npp:exc.payment-initiation-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.payment-initiation-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp-reject:src.npp-payment-initiation-messages-v4", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp-reject:AC05", "id": "AC05", "rail": "au-npp-reject", "class": "ReasonCode", "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, "guidance": "Send the instruction again from an open account." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "au-npp:txn.payment-initiation-instruction" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "au-npp:exc.payment-initiation-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.payment-initiation-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp-reject:src.npp-payment-initiation-messages-v4", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp-reject:AC06", "id": "AC06", "rail": "au-npp-reject", "class": "ReasonCode", "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, "guidance": "Sending the same instruction again will not lift a block. Find out why the account cannot be used first." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "au-npp:txn.payment-initiation-instruction" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "au-npp:exc.payment-initiation-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.payment-initiation-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp-reject:src.npp-payment-initiation-messages-v4", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp-reject:AC07", "id": "AC07", "rail": "au-npp-reject", "class": "ReasonCode", "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, "guidance": "Send a new instruction once the payee gives usable details." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "au-npp:txn.payment-initiation-instruction" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "au-npp:exc.payment-initiation-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.payment-initiation-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp-reject:src.npp-payment-initiation-messages-v4", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp-reject:AC13", "id": "AC13", "rail": "au-npp-reject", "class": "ReasonCode", "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, "guidance": "Send the instruction from an account that can be used on the platform." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "au-npp:txn.payment-initiation-instruction" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "au-npp:exc.payment-initiation-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.payment-initiation-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp-reject:src.npp-payment-initiation-messages-v4", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp-reject:AC14", "id": "AC14", "rail": "au-npp-reject", "class": "ReasonCode", "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, "guidance": "Sending the same instruction again will fail the same way. Use a different destination or a different route." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "au-npp:txn.payment-initiation-instruction" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "au-npp:exc.payment-initiation-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.payment-initiation-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp-reject:src.npp-payment-initiation-messages-v4", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp-reject:AC15", "id": "AC15", "rail": "au-npp-reject", "class": "ReasonCode", "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, "guidance": "Send a new instruction once the current mapping is confirmed." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "au-npp:txn.payment-initiation-instruction" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "au-npp:exc.payment-initiation-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.payment-initiation-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp-reject:src.npp-payment-initiation-messages-v4", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp-reject:AG01", "id": "AG01", "rail": "au-npp-reject", "class": "ReasonCode", "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, "guidance": "Sending the same instruction again will fail until the account is enabled." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "au-npp:txn.payment-initiation-instruction" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "au-npp:exc.payment-initiation-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.payment-initiation-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.mandate-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "concerns", "to": "au-npp:mandate.authorised-payment-mandate", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp-reject:src.npp-payment-initiation-messages-v4", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp-reject:AG03", "id": "AG03", "rail": "au-npp-reject", "class": "ReasonCode", "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, "guidance": "Try a different account or a different payment route." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "au-npp:txn.payment-initiation-instruction" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "au-npp:exc.payment-initiation-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.payment-initiation-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp-reject:src.npp-payment-initiation-messages-v4", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp-reject:AGNT", "id": "AGNT", "rail": "au-npp-reject", "class": "ReasonCode", "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, "guidance": "Send a corrected instruction once the routing is right." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "au-npp:txn.payment-initiation-instruction" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "au-npp:exc.payment-initiation-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.payment-initiation-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp-reject:src.npp-payment-initiation-messages-v4", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp-reject:AM01", "id": "AM01", "rail": "au-npp-reject", "class": "ReasonCode", "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, "guidance": "Send a corrected instruction with an amount above zero." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "au-npp:txn.payment-initiation-instruction" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "au-npp:exc.payment-initiation-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.payment-initiation-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.limits-a-zero-value-payment-is-forbidden", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp-reject:src.npp-payment-initiation-messages-v4", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp-reject:AM02", "id": "AM02", "rail": "au-npp-reject", "class": "ReasonCode", "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, "guidance": "Send a corrected instruction with an amount the institution accepts." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "au-npp:txn.payment-initiation-instruction" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "au-npp:exc.payment-initiation-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.payment-initiation-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp-reject:src.npp-payment-initiation-messages-v4", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp-reject:AM03", "id": "AM03", "rail": "au-npp-reject", "class": "ReasonCode", "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, "guidance": "Send the instruction from an account that can draw Australian dollars." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "au-npp:txn.payment-initiation-instruction" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "au-npp:exc.payment-initiation-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.payment-initiation-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp-reject:src.npp-payment-initiation-messages-v4", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp-reject:AM04", "id": "AM04", "rail": "au-npp-reject", "class": "ReasonCode", "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, "guidance": "Send the instruction again once the funds are available. Nothing settled, so nothing has to come back." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "au-npp:txn.payment-initiation-instruction" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "au-npp:exc.payment-initiation-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.payment-initiation-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp-reject:src.npp-payment-initiation-messages-v4", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp-reject:AM06", "id": "AM06", "rail": "au-npp-reject", "class": "ReasonCode", "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, "guidance": "Resending the same amount will fail again. Either the amount changes or the agreement does." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "au-npp:txn.payment-initiation-instruction" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "au-npp:exc.payment-initiation-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.payment-initiation-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.mandate-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "concerns", "to": "au-npp:mandate.authorised-payment-mandate", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp-reject:src.npp-payment-initiation-messages-v4", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp-reject:AM09", "id": "AM09", "rail": "au-npp-reject", "class": "ReasonCode", "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, "guidance": "The amount has to match the agreement, or the agreement has to change and be authorised again." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "au-npp:txn.payment-initiation-instruction" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "au-npp:exc.payment-initiation-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.payment-initiation-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.mandate-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "concerns", "to": "au-npp:mandate.authorised-payment-mandate", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp-reject:src.npp-payment-initiation-messages-v4", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp-reject:AM12", "id": "AM12", "rail": "au-npp-reject", "class": "ReasonCode", "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, "guidance": "Send a corrected instruction." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "au-npp:txn.payment-initiation-instruction" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "au-npp:exc.payment-initiation-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.payment-initiation-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp-reject:src.npp-payment-initiation-messages-v4", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp-reject:AM19", "id": "AM19", "rail": "au-npp-reject", "class": "ReasonCode", "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, "guidance": "Correct the file and send it again." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "au-npp:txn.payment-initiation-instruction" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "au-npp:exc.payment-initiation-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.payment-initiation-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp-reject:src.npp-payment-initiation-messages-v4", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp-reject:AM21", "id": "AM21", "rail": "au-npp-reject", "class": "ReasonCode", "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, "guidance": "The limit is between the payer and their institution. Resending will fail until the limit changes." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "au-npp:txn.payment-initiation-instruction" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "au-npp:exc.payment-initiation-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.payment-initiation-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.mandate-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "concerns", "to": "au-npp:mandate.authorised-payment-mandate", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp-reject:src.npp-payment-initiation-messages-v4", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp-reject:BE06", "id": "BE06", "rail": "au-npp-reject", "class": "ReasonCode", "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, "guidance": "Confirm the details before sending again." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "au-npp:txn.payment-initiation-instruction" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "au-npp:exc.payment-initiation-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.payment-initiation-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp-reject:src.npp-payment-initiation-messages-v4", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp-reject:BE08", "id": "BE08", "rail": "au-npp-reject", "class": "ReasonCode", "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, "guidance": "Correct the instruction and send it again." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "au-npp:txn.payment-initiation-instruction" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "au-npp:exc.payment-initiation-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.payment-initiation-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp-reject:src.npp-payment-initiation-messages-v4", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp-reject:BE22", "id": "BE22", "rail": "au-npp-reject", "class": "ReasonCode", "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, "guidance": "Correct the instruction and send it again." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "au-npp:txn.payment-initiation-instruction" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "au-npp:exc.payment-initiation-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.payment-initiation-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp-reject:src.npp-payment-initiation-messages-v4", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp-reject:CH20", "id": "CH20", "rail": "au-npp-reject", "class": "ReasonCode", "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, "guidance": "Correct the formatting and send the instruction again." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "au-npp:txn.payment-initiation-instruction" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "au-npp:exc.payment-initiation-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.payment-initiation-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp-reject:src.npp-payment-initiation-messages-v4", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp-reject:CH21", "id": "CH21", "rail": "au-npp-reject", "class": "ReasonCode", "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, "guidance": "Correct the message and send it again." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "au-npp:txn.payment-initiation-instruction" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "au-npp:exc.payment-initiation-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.payment-initiation-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp-reject:src.npp-payment-initiation-messages-v4", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp-reject:CURR", "id": "CURR", "rail": "au-npp-reject", "class": "ReasonCode", "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, "guidance": "Correct the currency and send the instruction again." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "au-npp:txn.payment-initiation-instruction" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "au-npp:exc.payment-initiation-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.payment-initiation-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp-reject:src.npp-payment-initiation-messages-v4", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp-reject:DT02", "id": "DT02", "rail": "au-npp-reject", "class": "ReasonCode", "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, "guidance": "Correct the timestamp and send the instruction again." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "au-npp:txn.payment-initiation-instruction" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "au-npp:exc.payment-initiation-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.payment-initiation-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp-reject:src.npp-payment-initiation-messages-v4", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp-reject:DT04", "id": "DT04", "rail": "au-npp-reject", "class": "ReasonCode", "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, "guidance": "Send the instruction on the day the payment should be made." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "au-npp:txn.payment-initiation-instruction" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "au-npp:exc.payment-initiation-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.payment-initiation-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp-reject:src.npp-payment-initiation-messages-v4", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp-reject:FF10", "id": "FF10", "rail": "au-npp-reject", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "au-npp:txn.payment-initiation-instruction" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "au-npp:exc.payment-initiation-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.payment-initiation-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp-reject:src.npp-payment-initiation-messages-v4", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp-reject:MD01", "id": "MD01", "rail": "au-npp-reject", "class": "ReasonCode", "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, "guidance": "Send the instruction again with the agreement identifier in it." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "au-npp:txn.payment-initiation-instruction" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "au-npp:exc.payment-initiation-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.payment-initiation-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.mandate-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "concerns", "to": "au-npp:mandate.authorised-payment-mandate", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.mandate-a-mandate-is-a-record-in-the-scheme-operators-database", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp-reject:src.npp-payment-initiation-messages-v4", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp-reject:NARR", "id": "NARR", "rail": "au-npp-reject", "class": "ReasonCode", "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, "guidance": "Whether to send again depends entirely on what the narrative says." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "au-npp:txn.payment-initiation-instruction" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "au-npp:exc.payment-initiation-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.payment-initiation-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp-reject:src.npp-payment-initiation-messages-v4", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp-reject:NAUT", "id": "NAUT", "rail": "au-npp-reject", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "au-npp:txn.payment-initiation-instruction" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "au-npp:exc.payment-initiation-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.payment-initiation-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.mandate-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "concerns", "to": "au-npp:mandate.authorised-payment-mandate", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.mandate-a-request-may-not-be-sent-unless-the-mandate-is-active", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp-reject:src.npp-payment-initiation-messages-v4", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "au-npp-reject:TD03", "id": "TD03", "rail": "au-npp-reject", "class": "ReasonCode", "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, "guidance": "Rebuild the file correctly and send it again." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "au-npp:txn.payment-initiation-instruction" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "au-npp:exc.payment-initiation-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "au-npp:role.payer-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-an-institution-may-offer-alternative-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-payment-initiation-leg-is-proprietary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-the-interbank-reason-code-values-are-not-public", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "au-npp:rule.messages-no-published-deadline-for-a-payment-initiation-status-report", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "au-npp:txn.payment-initiation-instruction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "au-npp:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "au-npp-reject:src.npp-payment-initiation-messages-v4", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rail.bancontact", "id": "rail.bancontact", "class": "Rail", "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)", "country": "BE", "currency": "EUR", "operators": [ "Bancontact Company SA/NV, for the card scheme, the Bancontact Pay app and Bancontact Pro", "MultiSafepay B.V., acquirer of the Bancontact leg of Bancontact Pro (Merchant T&C, version date 2026-03-01)" ], "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" ], "relations": [ { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 1 and articles 7 to 9", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.scf-response-2014", "section": "whole document", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.app-terms-8-0", "section": "articles 1 to 3 and 6", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "source_class": null, "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:exc.refund", "id": "exc.refund", "rail": "bancontact", "class": "Exception", "name": "Merchant refund", "summary": "A merchant returns all or part of a SUCCEEDED, bulked Bancontact Pro payment to the payer through the Refund API, for any reason. The refund is taken from the running balance of the current bulking period and so from that day's payout.", "money_moves": true, "outcome": "Bancontact Company sends the refund to the payer and pays the merchant only the net of payments less refunds; a refund that would make the period's balance negative is declined. That the refund reaches the payer as a SEPA credit transfer is [Inference] from the refund remittance format in the payouts guide.", "relations": [ { "type": "initiated_by", "to": "bancontact:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "bancontact:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "bancontact:rule.refund-api-conditions", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "bancontact:rule.refund-netted-from-payout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 1, definition of Refund; article 9.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.portal-refunds-052025", "section": "Introduction", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C articles 1 and 9.3; refunds guide; payouts guide; read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the merchant initiates a full or partial refund of a SUCCEEDED payment, netted against the day's payout, article 1 and article 9.3." }, { "source": "bancontact:src.portal-refunds-052025", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the Refund API enables full or partial refunds of SUCCEEDED payments, deducted from the ongoing settlement payout and refused if funds are insufficient." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "bancontact:rule.refund-api-conditions", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.refund-netted-from-payout", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "bancontact:exc.void", "id": "exc.void", "rail": "bancontact", "class": "Exception", "name": "Void of a held payment", "summary": "With the optional void service, Bancontact Company holds a bulked payment's funds until the merchant confirms or cancels it through the Void API, or until 168 hours pass. A cancellation or the time-out turns the payment into a void and the money goes back to the payer. The API shows the held state as PENDING_MERCHANT_AKNOWLEDGMENT and the result as VOIDED.", "money_moves": true, "outcome": "On confirmation the payment becomes SUCCEEDED and is paid out; on cancellation or time-out Bancontact Company makes reasonable efforts to return the funds to the payer and confirms the void to the merchant.", "relations": [ { "type": "initiated_by", "to": "bancontact:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "bancontact:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "bancontact:rule.void-hold-168-hours", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 9.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.portal-errors-statuses-052025", "section": "Payment Statuses", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C article 9.2; errors and statuses guide; read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the void service holds funds until acknowledgement, cancellation, or 168 hours pass, article 9.2." }, { "source": "bancontact:src.portal-errors-statuses-052025", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms PENDING_MERCHANT_AKNOWLEDGMENT and VOIDED as payment statuses used by the void service." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "bancontact:rule.void-hold-168-hours", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "bancontact:exc.wero-chargeback", "id": "exc.wero-chargeback", "rail": "bancontact", "class": "Exception", "name": "Wero chargeback and representment", "summary": "After a Wero payment through Bancontact Pro has settled, the payer disputes it and the payer's bank raises a chargeback under EPI's rules. Bancontact Company credits the payer's bank and debits the merchant. It then decides whether the case can be answered with a representment, using evidence the merchant supplies. A Bancontact payment has no such path.", "money_moves": true, "outcome": "The chargeback amount is owed by the merchant at once, netted from that day's payout or requested separately, plus a non-refundable fee; if Bancontact Company represents and the representment goes through, the amount comes back to the merchant with that day's payout. How EPI decides between chargeback and representment is not read.", "relations": [ { "type": "initiated_by", "to": "bancontact:role.payer-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "bancontact:role.bancontact-company", "note": "Bancontact Company decides whether to represent; the outcome between the banks follows EPI's scheme rules, which Orca has not read.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "bancontact:rule.wero-chargeback", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "bancontact:rule.representment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "bancontact:rule.unauthorised-claims-outside-chargeback", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 1, definitions of Chargeback and Representment; articles 7.5 and 8", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C articles 1, 7.5 and 8; read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the definitions of Chargeback and Representment, and the chargeback and representment process, article 1 and articles 7.5 and 8." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "bancontact:rule.representment", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.wero-chargeback", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "bancontact:role.acquirer", "id": "role.acquirer", "rail": "bancontact", "class": "Role", "name": "Acquirer", "summary": "A Bancontact scheme member that contracts with merchants or payment collectors so they can accept Bancontact payments. For the Bancontact leg of Bancontact Pro, the Merchant T&C of 2026-03-01 name MultiSafepay B.V., Amsterdam, a payment institution supervised by De Nederlandsche Bank. The scheme lets a member take an acquiring licence alone (SCF response, 2014).", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 1, definition of Acquirer", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.scf-response-2014", "section": "questions 10 and 14", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C article 1; SCF response questions 10 and 14; read 2026-09-19. The acquirer named may change with a later edition of the terms.", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms MultiSafepay B.V. Amsterdam as the current Acquirer, a payment institution supervised by De Nederlandsche Bank, article 1 definition." }, { "source": "bancontact:src.scf-response-2014", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms members may take an acquiring licence alone and that acquiring is open to competition, questions 10 and 14." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "bancontact:rule.blocking-and-termination", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.card-scheme-authentication", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.co-badged-cards", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.operator-and-acquirer", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.scheme-membership", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "bancontact:role.bancontact-company", "id": "role.bancontact-company", "rail": "bancontact", "class": "Role", "name": "Bancontact Company", "summary": "Bancontact Company SA/NV, Brussels, enterprise number 0675.984.882: a payment institution supervised by the National Bank of Belgium. It owns the Bancontact brand and writes the card scheme rules (not public), provides the Bancontact Pay app and its authentication on the card issuers' behalf, and runs Bancontact Pro, collecting payments into a segregated account and paying merchants out. The developer portal still calls it Bancontact Payconiq Company.", "kind": "operator", "relations": [ { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 1, definition of BC", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.app-terms-8-0", "section": "articles 2 and 3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.about-us-page", "section": "company statement on supervision", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.portal-payouts-052025", "section": "Remittance Information", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C article 1; App T&C articles 2 and 3; About us page; payouts guide; read 2026-09-19. That the portal's Bancontact Payconiq Company is the same company is [Inference] from the shared enterprise number in both terms.", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.portal-payouts-052025", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the developer portal remittance text still names Bancontact Payconiq Company's segregated account." }, { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms Bancontact Company SA/NV, Brussels, enterprise number 0675.984.882, a payment institution under National Bank of Belgium supervision, article 1 definition of BC." }, { "source": "bancontact:src.app-terms-8-0", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms Bancontact Company provides the app and authenticates Mobile Bancontact Transactions on the card issuer's behalf, articles 2 and 3." }, { "source": "bancontact:src.about-us-page", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms Bancontact Company is a regulated payment institution under National Bank of Belgium supervision." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "bancontact:exc.wero-chargeback", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.acceptance-service-wero-first", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.api-errors", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.api-keys-and-signatures", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.app-and-card-blocking", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.app-cards-and-private-p2p", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.app-limits-over-card-limits", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.app-operator-liability-limits", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.bancontact-leg-no-chargeback", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.blocking-and-termination", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.bulk-closing-time", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.bulked-payout-next-working-day", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.card-scheme-processing-model", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.dispute-evidence-signed-succeeded", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.individual-payout-invoice", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.liability-cap-twelve-months-fees", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.merchant-eligibility", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.operator-and-acquirer", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.payer-bank-credits-segregated-account", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.payment-statuses", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.payout-iban-responsibility", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.refund-netted-from-payout", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.refusal-and-suspension", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.remittance-information", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.representment", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.restricted-activities", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.scheme-membership", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.succeeded-guarantees-payout", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.void-hold-168-hours", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.wero-chargeback", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "bancontact:role.card-issuer", "id": "role.card-issuer", "rail": "bancontact", "class": "Role", "name": "Card issuer", "summary": "The licensed financial institution that issued a Bancontact card linked to the cardholder's payment account. It authorises card transactions, and its own terms govern the card and every Mobile Bancontact Transaction made with it; questions and complaints about a transaction go to it, not to Bancontact Company. Bancontact Company issues no cards.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "bancontact:src.app-terms-8-0", "section": "articles 1.4, 2, 3, 6.2.4 and 21", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.scf-response-2014", "section": "questions 13 and 16", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "App T&C articles 1.4, 2, 3, 6.2.4 and 21; SCF response questions 13 and 16; read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Bancontact Pay App T&C version 8.0, applicable from 2026-03-01. The date is that version's start date; the provision may be older [Unverified].", "source_edition": "Bancontact Pay App Terms and Conditions, version 8.0, applicable from 2026-03-01, English PDF of 12 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.app-terms-8-0", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms Bancontact Company issues no cards, the card issuer's own terms govern the card and Mobile Bancontact Transactions, and complaints about a transaction go to the issuer, articles 1.4, 6.2.4 and 21." }, { "source": "bancontact:src.scf-response-2014", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms issuers can hold an issuing-only licence and that transactions are authorised by the issuer, questions 13 and 16." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "bancontact:rule.app-and-card-blocking", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.app-limits-over-card-limits", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.app-operator-liability-limits", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.card-rights-issuer-terms", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.card-scheme-authentication", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.co-badged-cards", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.contactless-no-pin-50-eur", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.issuer-approves", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.no-payer-recall-in-app-terms", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.scheme-membership", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "bancontact:role.epi", "id": "role.epi", "rail": "bancontact", "class": "Role", "name": "European Payments Initiative (EPI)", "summary": "The scheme manager of Wero, which sets its rules, practices and standards. Its scheme rules decide how long after a Wero payment a chargeback may arrive, and it may instruct Bancontact Company to refuse payments or suspend or end a merchant's service. Orca has not read EPI's rules.", "kind": "authority", "relations": [ { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 1, definition of EPI; articles 8, 12.1.1 and 16.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C articles 1, 8, 12.1.1 and 16.3; read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms EPI is Wero's scheme manager setting harmonised rules, and can instruct BC to refuse a payment or suspend or end a merchant's service, article 1 and articles 8, 12.1.1 and 16.3." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "bancontact:rule.blocking-and-termination", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.operator-and-acquirer", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.wero-leg-sepa-instant", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "bancontact:role.merchant", "id": "role.merchant", "rail": "bancontact", "class": "Role", "name": "Merchant", "summary": "The business, person or organisation, acting professionally, that accepts payments for goods or services. Under Bancontact Pro it contracts with Bancontact Company, must act for its own account, and is paid out to its own Payout IBAN. For card payments outside Bancontact Pro it contracts with an acquirer [Inference: the scheme's acquiring model, SCF response question 10].", "kind": "party", "relations": [ { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 1, definition of Merchant; article 6.1 II", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.scf-response-2014", "section": "question 10", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C articles 1 and 6.1; SCF response question 10; read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the definition of Merchant acting professionally and the duty to act for its own account, not for third parties, article 1 and article 6.1 II." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "bancontact:exc.refund", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:exc.refund", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:exc.void", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:exc.void", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.api-errors", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.api-keys-and-signatures", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.brand-display-parity", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.dispute-evidence-signed-succeeded", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.liability-cap-twelve-months-fees", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.merchant-eligibility", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.merchant-legal-compliance", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.no-merchant-minimum-or-maximum", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.no-surcharge", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.payconiq-url-change", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.payout-iban-responsibility", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.refund-api-conditions", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.refund-iban-lookup", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.refund-netted-from-payout", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.refund-policy-disclosure", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.representment", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.restricted-activities", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.void-hold-168-hours", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.wero-chargeback", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "bancontact:role.nbb", "id": "role.nbb", "rail": "bancontact", "class": "Role", "name": "National Bank of Belgium (NBB)", "summary": "The Belgian central bank, which supervises Bancontact Company as a payment institution. No NBB oversight report on the Bancontact scheme was read.", "kind": "authority", "relations": [ { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 1, definition of BC", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.about-us-page", "section": "company statement on supervision", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C article 1; About us page; read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms BC is a payment institution under supervision of the Belgian National Bank, article 1 definition of BC." }, { "source": "bancontact:src.about-us-page", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms Bancontact Company operates under supervision of the National Bank of Belgium." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "bancontact:rule.operator-and-acquirer", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "bancontact:role.partner", "id": "role.partner", "rail": "bancontact", "class": "Role", "name": "Partner", "summary": "A person that, with Bancontact Company's approval, enables a merchant to use Bancontact Pro, such as an integrator, or promotes it for Bancontact Company. A merchant that signed through a partner may meet its notice duties by telling the partner; the merchant stays liable to Bancontact Company for any third party it engages to integrate.", "kind": "service_provider", "relations": [ { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 1, definition of Partner; articles 5.1, 11.2 and 18.4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C articles 1, 5.1, 11.2 and 18.4; read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the definition of Partner, that BC may share the API key with the third parties charged with technical integration, that the merchant stays liable for a third party it engages, and that notifying a named Partner can satisfy the merchant's notice duty, article 1 and articles 5.1, 11.2 and 18.4." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "bancontact:rule.api-keys-and-signatures", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.liability-cap-twelve-months-fees", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.payconiq-url-change", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "bancontact:role.payer-bank", "id": "role.payer-bank", "rail": "bancontact", "class": "Role", "name": "Payer's bank", "summary": "The payer's payment service provider under Bancontact Pro. It approves or declines the payment and credits Bancontact Company's account for each successful one; for a Wero payment it sends the SEPA instant credit transfer and is the party that raises a chargeback when the payer disputes the payment under EPI's rules. For a Bancontact payment this role is filled by the card issuer [Inference].", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 1, definition of Chargeback; articles 7.2.1 and 7.5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C articles 1, 7.2.1 and 7.5; read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms only payments the payer bank approves are credited, each successful payment is credited by the payer's bank on BC's account, and the payer's bank raises a Wero chargeback, article 1 definition of Chargeback and articles 7.2.1 and 7.5." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "bancontact:exc.wero-chargeback", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.issuer-approves", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.payer-bank-credits-segregated-account", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.unauthorised-claims-outside-chargeback", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.wero-chargeback", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.wero-leg-sepa-instant", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "bancontact:role.payer", "id": "role.payer", "rail": "bancontact", "class": "Role", "name": "Payer", "summary": "The person who pays: a Bancontact cardholder paying at a terminal or online, a user of the Bancontact Pay app authorising a Mobile Bancontact Transaction with a Mobile PIN or biometrics, or, under Bancontact Pro, a consumer who scans the merchant's QR code or opens a payment link in an app and pays by Wero or by Bancontact. The Merchant T&C call this party the Payer; the App T&C call the app holder the User.", "kind": "party", "relations": [ { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 1, definition of Payer", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.app-terms-8-0", "section": "article 2, definitions of User and Mobile Bancontact Transaction", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C article 1; App T&C article 2; read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19; Bancontact Pay App Terms and Conditions, version 8.0, applicable from 2026-03-01, English PDF of 12 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the definition of Payer as a consumer using an app to initiate a payment transaction, article 1." }, { "source": "bancontact:src.app-terms-8-0", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the App T&C definitions of User and Mobile Bancontact Transaction, authenticated with a Mobile PIN or biometrics, article 2." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "bancontact:rule.app-and-card-blocking", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.app-cards-and-private-p2p", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.app-operator-liability-limits", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.no-payer-recall-in-app-terms", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "bancontact:rule.acceptance-service-wero-first", "id": "rule.acceptance-service-wero-first", "rail": "bancontact", "class": "Rule", "name": "Bancontact Pro: one QR code or link, Wero first, Bancontact as fallback", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 1, definitions of Acceptance Service, Bancontact and Wero", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 7.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.what-is-bancontact-pro-page", "section": "introduction and feature list", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.bancontact-company", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.pro-wero", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C articles 1 and 7.1; What is Bancontact Pro page; read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the Acceptance Service lets a merchant take payment through one QR code or link, with Wero payments accepted or Bancontact payments where Wero is not possible, article 1 and article 7.1." }, { "source": "bancontact:src.what-is-bancontact-pro-page", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the merchant page presents Bancontact Pro as accepting both Bancontact and Wero through the Bancontact Pay app and bank apps." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rule.api-errors", "id": "rule.api-errors", "rail": "bancontact", "class": "Rule", "name": "API error codes and how to react to them", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "bancontact:src.portal-errors-statuses-052025", "section": "HTTP Status Codes; Error Response Structure; Common Error Codes; Best Practices", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.portal-refunds-052025", "section": "Get Refund IBAN, error codes", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.bancontact-company", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.pro-wero", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Errors and statuses guide and refunds guide, read 2026-09-19; codes grouped in Orca's own order. The refunds guide also uses REFUND_NOT_AVAILABLE, which the common list does not name.", "confidence": "high" }, "currency": { "effective_since": "Unknown: the guide gives no effective date", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Bancontact Pro developer portal guide versioned 052025. The guide gives no effective date; the version suffix suggests May 2025 [Inference].", "source_edition": "Bancontact Pro Developer Portal, API Errors, Statuses, and Responses, guide version 052025, read from the page data on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.portal-errors-statuses-052025", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the HTTP status codes, the error response structure with code, message, traceId and spanId, the thirteen common error codes, and the retry and rate-limit advice." }, { "source": "bancontact:src.portal-refunds-052025", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the getRefundIban endpoint uses the additional error code REFUND_NOT_AVAILABLE not in the common list." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rule.api-keys-and-signatures", "id": "rule.api-keys-and-signatures", "rail": "bancontact", "class": "Rule", "name": "API keys and JSON Web Signatures", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 1, definitions of API Key(s), Digital signatures and JSON Web Key Sets", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 5.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.portal-refunds-052025", "section": "Introduction", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.partner", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.bancontact-company", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.pro-wero", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C articles 1 and 5.1; refunds guide; read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the definitions of API Key, Digital signatures and JSON Web Key Sets, and that the merchant generates an API key shared with the integrator, article 1 and article 5.1." }, { "source": "bancontact:src.portal-refunds-052025", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the create refund endpoint requires a JSON Web Signature and activation by the support team." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rule.app-and-card-blocking", "id": "rule.app-and-card-blocking", "rail": "bancontact", "class": "Rule", "name": "Blocking the app or a card", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "bancontact:src.app-terms-8-0", "section": "articles 4, 7.3, 8 and 18.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.bancontact-card-page", "section": "lost card section", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.bancontact-company", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.payer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.card-issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2p", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "App T&C articles 4, 7.3, 8 and 18.3; Bancontact card page; read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Bancontact Pay App T&C version 8.0, applicable from 2026-03-01. The date is that version's start date; the provision may be older [Unverified].", "source_edition": "Bancontact Pay App Terms and Conditions, version 8.0, applicable from 2026-03-01, English PDF of 12 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.app-terms-8-0", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms three wrong PINs block the app, Card Stop blocks the app or a card on notification, and Bancontact Company may disable or block for security or breach, articles 4, 7.3, 8 and 18.3." }, { "source": "bancontact:src.bancontact-card-page", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms a lost card can be blocked instantly via the banking app or by calling Card Stop." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rule.app-cards-and-private-p2p", "id": "rule.app-cards-and-private-p2p", "rail": "bancontact", "class": "Rule", "name": "App: up to five cards, person to person for private use only", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "bancontact:src.app-terms-8-0", "section": "articles 5, 6.1.1, 6.1.2 and 6.2.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.about-us-page", "section": "Bancontact Pay brand description", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.payer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.bancontact-company", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2p", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "App T&C articles 5 and 6; About us page; read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Bancontact Pay App T&C version 8.0, applicable from 2026-03-01. The date is that version's start date; the provision may be older [Unverified].", "source_edition": "Bancontact Pay App Terms and Conditions, version 8.0, applicable from 2026-03-01, English PDF of 12 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.app-terms-8-0", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms up to five cards from multiple issuers can be registered with one default, P2P receipt is for private individuals only, the app is offered in EU app stores, and the user keeps an accurate account, articles 5, 6.1.1, 6.1.2 and 6.2.1." }, { "source": "bancontact:src.about-us-page", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the Bancontact Pay brand description mentioning payers can also use their own trusted bank app." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rule.app-limits-over-card-limits", "id": "rule.app-limits-over-card-limits", "rail": "bancontact", "class": "Rule", "name": "App limits apply on top of card limits; the lower wins", "statement": "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.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "bancontact:src.app-terms-8-0", "section": "article 6.2.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.bancontact-company", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.card-issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2p", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "App T&C article 6.2.3, read 2026-09-19. The limit values on bancontact.com/en/faq did not load and are [Unverified].", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Bancontact Pay App T&C version 8.0, applicable from 2026-03-01. The date is that version's start date; the provision may be older [Unverified].", "source_edition": "Bancontact Pay App Terms and Conditions, version 8.0, applicable from 2026-03-01, English PDF of 12 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.app-terms-8-0", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms app-level limits apply on top of card limits, the lowest prevails, the app disables an exceeded card, and available limits decrease as payments are sent or received, article 6.2.3." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rule.app-operator-liability-limits", "id": "rule.app-operator-liability-limits", "rail": "bancontact", "class": "Rule", "name": "Bancontact Company is not liable for how card transactions are executed", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "bancontact:src.app-terms-8-0", "section": "articles 3, 6.2.4, 9.1 to 9.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.bancontact-company", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.payer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.card-issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2p", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "App T&C articles 3, 6.2.4 and 9, read 2026-09-19. How far these exclusions hold against a consumer under payment services law is not assessed [Unverified].", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Bancontact Pay App T&C version 8.0, applicable from 2026-03-01. The date is that version's start date; the provision may be older [Unverified].", "source_edition": "Bancontact Pay App Terms and Conditions, version 8.0, applicable from 2026-03-01, English PDF of 12 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.app-terms-8-0", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms Bancontact Company provides the app and authentication on the issuer's behalf, issues no cards, excludes liability for non-execution and unauthorised device or PIN use except for its own intentional act or fraud, articles 3, 6.2.4 and 9.1 to 9.3." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rule.bancontact-leg-no-chargeback", "id": "rule.bancontact-leg-no-chargeback", "rail": "bancontact", "class": "Rule", "name": "The Bancontact leg of Bancontact Pro cannot be charged back", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 1, definition of Chargeback", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 8", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.bancontact-company", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "bancontact:rule.card-payments-no-chargeback-per-processors", "note": "The wider rule, and it rests on other sources. That record reaches Bancontact card and mobile payments online from two processors' documentation, where this record covers only the Bancontact leg of Bancontact Pro from the operator's own merchant terms.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C article 1, definition of Chargeback, article 8, read 2026-09-19, stated in Orca's own words.", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the definition of Chargeback states a Bancontact payment cannot be charged back, article 1 and article 8." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "bancontact:rule.card-payments-no-chargeback-per-processors", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "bancontact:rule.blocking-and-termination", "id": "rule.blocking-and-termination", "rail": "bancontact", "class": "Rule", "name": "Blocking the merchant's service and ending it at once", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "articles 12.2.1 to 12.2.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "articles 16.2 and 16.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.bancontact-company", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.acquirer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.epi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.pro-wero", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C articles 12.2.1 to 12.2.3, articles 16.2 and 16.3, read 2026-09-19, stated in Orca's own words.", "confidence": "medium" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the blocking grounds and process in articles 12.2.1 to 12.2.3, and the termination and immediate-termination grounds in articles 16.2 and 16.3." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rule.brand-display-parity", "id": "rule.brand-display-parity", "rail": "bancontact", "class": "Rule", "name": "Display the Bancontact Pro brands on equal terms", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 6.5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.pro-wero", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C article 6.5, read 2026-09-19, stated in Orca's own words.", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the merchant must display the acceptance logos prominently, follow the brand instructions, and not discriminate against the brands relative to other accepted payment methods, article 6.5." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rule.bulk-closing-time", "id": "rule.bulk-closing-time", "rail": "bancontact", "class": "Rule", "name": "Bulk period runs from closing time to closing time", "statement": "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.", "rests_on": "rule", "facet": "hours", "parameters": { "time_window": { "times": [ "00:00" ], "timezone": "Europe/Brussels", "on": "calendar_day", "text": "default bulk closing time 00:00 CET, changeable by the merchant" } }, "relations": [ { "type": "sourced_from", "to": "bancontact:src.portal-payouts-052025", "section": "Payment Bulking", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.bancontact-company", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.pro-wero", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct:hours", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Payouts guide, Payment Bulking, read 2026-09-19. The guide writes CET; the time zone below is Belgium's [Inference].", "confidence": "high" }, "currency": { "effective_since": "Unknown: the guide gives no effective date", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Bancontact Pro developer portal guide versioned 052025. The guide gives no effective date; the version suffix suggests May 2025 [Inference].", "source_edition": "Bancontact Pro Developer Portal, Payouts, Bulking and Remittance Information, guide version 052025, read from the page data on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.portal-payouts-052025", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the default closing time is 00:00 CET, and that Friday, Saturday and Sunday transactions follow the same logic but may only reach the merchant on Monday or Tuesday depending on its bank." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rule.bulked-payout-next-working-day", "id": "rule.bulked-payout-next-working-day", "rail": "bancontact", "class": "Rule", "name": "Bulked payout by SEPA credit transfer on the next working day", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 1, definitions of Bulk Instruction and Working Day", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 7.4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.portal-payouts-052025", "section": "Payouts; Payment Bulking", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.bancontact-company", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.pro-wero", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C article 1, definitions of Bulk Instruction and Working Day, article 7.4, read 2026-09-19, stated in Orca's own words.", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the definitions of Bulk Instruction and Working Day and the bulking mechanism paying out on the following working day, article 1 and article 7.4." }, { "source": "bancontact:src.portal-payouts-052025", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms bulked payouts are made by SEPA credit transfer and executed the working day after." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rule.card-payments-no-chargeback-per-processors", "id": "rule.card-payments-no-chargeback-per-processors", "rail": "bancontact", "class": "Rule", "name": "Processors: Bancontact card and app payments have no chargebacks", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "bancontact:src.stripe-bancontact", "section": "payment method properties; Disputes", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.adyen-bancontact-card", "section": "feature table, Chargebacks column", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.card-online", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "bancontact:rule.bancontact-leg-no-chargeback", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Stripe Docs, Bancontact payments; Adyen Docs, Bancontact card; both read 2026-09-19. Two processors on different hosts, each describing its own integration. Whether the scheme rules provide any chargeback or dispute right for in-store card payments is [Unverified].", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the processors' pages carry no date", "effective_to": null, "effective_note": "Drafted 2026-09-19 from processors' documentation pages, which describe their own integrations and carry no date. The Bancontact scheme rules are not public, so the record carries primary_not_public and needs two independent sources on different hosts before it can be corroborated.", "source_edition": "Stripe Docs, Bancontact payments, live page read 2026-09-19; Adyen Docs, Bancontact card, live page read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source": "bancontact:src.stripe-bancontact", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms Stripe lists dispute support as no for Bancontact and explains the payer authenticates with the bank, so no chargeback follows." }, { "source": "bancontact:src.adyen-bancontact-card", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms Adyen's feature table marks chargebacks unsupported for Bancontact card payments online." }, { "source": "bancontact:src.adyen-docs-bancontact-mobile", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms Adyen's feature table also marks chargebacks unsupported for Bancontact mobile payments, checked separately from the card page since that page alone does not cover the mobile product." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "bancontact:rule.bancontact-leg-no-chargeback", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "bancontact:rule.card-rights-issuer-terms", "id": "rule.card-rights-issuer-terms", "rail": "bancontact", "class": "Rule", "name": "The cardholder's rights sit in the card issuer's terms", "statement": "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].", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "bancontact:src.app-terms-8-0", "section": "articles 1.4, 6.2.2, 6.2.4 and 21", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.card-issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.card-in-store", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.card-online", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2p", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "App T&C articles 1.4, 6.2.2, 6.2.4 and 21, read 2026-09-19. No issuer's terms and no law were read.", "confidence": "medium" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Bancontact Pay App T&C version 8.0, applicable from 2026-03-01. The date is that version's start date; the provision may be older [Unverified].", "source_edition": "Bancontact Pay App Terms and Conditions, version 8.0, applicable from 2026-03-01, English PDF of 12 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.app-terms-8-0", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the card and its transactions are governed by the Card Issuer T&Cs, not the app terms, and that transaction complaints go to the issuer, articles 1.4, 6.2.2, 6.2.4 and 21." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rule.card-scheme-authentication", "id": "rule.card-scheme-authentication", "rail": "bancontact", "class": "Rule", "name": "Card scheme: issuer authorisation, chip and PIN, strong authentication online", "statement": "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.", "rests_on": "guidance", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "bancontact:src.scf-response-2014", "section": "questions 16, 23 a and 26", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.adyen-bancontact-card", "section": "introduction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.card-issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.acquirer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.card-in-store", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.card-online", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "SCF response questions 16, 23 a and 26 (May 2014); Adyen Docs, Bancontact card; read 2026-09-19. The card present lines rest on the 2014 answer alone [Unverified today].", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the 2014 answer describes the scheme as it then was", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the scheme's May 2014 answer to the Eurosystem, the only scheme-level document the operator publishes. It describes the scheme as it stood in 2014, before PSD2 and the Interchange Fee Regulation; whether it still holds is [Unverified]. The scheme rules are not public, so the record carries primary_not_public and needs two independent sources on different hosts before it can be corroborated.", "source_edition": "Response of the Bancontact/Mister Cash card scheme to the Eurosystem questionnaire on SEPA compliance of card schemes, Bancontact SA/NV, May 2014, English PDF of 13 pages, read in full 2026-09-19; Adyen Docs, Bancontact card, live page read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "primary_not_public": true, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rule.card-scheme-processing-model", "id": "rule.card-scheme-processing-model", "rail": "bancontact", "class": "Rule", "name": "Card scheme: authorisation, clearing and settlement may run on different providers", "statement": "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.", "rests_on": "guidance", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "bancontact:src.scf-response-2014", "section": "questions 6 a, 9 a and 15", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.bancontact-company", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.card-in-store", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.card-online", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2p", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "SCF response questions 6 a, 9 a and 15 (May 2014), read 2026-09-19. One source only; a second independent source is needed before corroboration.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the scheme described it as in place when it answered the Eurosystem", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the scheme's May 2014 answer to the Eurosystem, the only scheme-level document the operator publishes. It describes the scheme as it stood in 2014, before PSD2 and the Interchange Fee Regulation; whether it still holds is [Unverified]. The scheme rules are not public, so the record carries primary_not_public and needs two independent sources on different hosts before it can be corroborated.", "source_edition": "Response of the Bancontact/Mister Cash card scheme to the Eurosystem questionnaire on SEPA compliance of card schemes, Bancontact SA/NV, May 2014, English PDF of 13 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "primary_not_public": true, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rule.co-badged-cards", "id": "rule.co-badged-cards", "rail": "bancontact", "class": "Rule", "name": "Co-badged Bancontact cards can run on the other scheme", "statement": "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].", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "bancontact:src.adyen-co-badged-cards", "section": "introduction; which transactions are impacted; routing issues", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.adyen-bancontact-card", "section": "introduction, co-badged cards", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.card-issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.acquirer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.card-in-store", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.card-online", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:participants", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:participants", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Adyen Docs, co-badged Bancontact cards and Bancontact card pages, read 2026-09-19; two pages on one host count as one source, so a second independent source is needed before corroboration. The co-badge regulation Adyen points to (the Interchange Fee Regulation's co-badging rules) was not read; that the other network's rules then apply is [Inference].", "confidence": "medium" }, "currency": { "effective_since": "Unknown: Adyen's page describes cards issued from early 2021", "effective_to": null, "effective_note": "Drafted 2026-09-19 from processors' documentation pages, which describe their own integrations and carry no date. The Bancontact scheme rules are not public, so the record carries primary_not_public and needs two independent sources on different hosts before it can be corroborated.", "source_edition": "Adyen Docs, Issues processing co-badged Bancontact cards, live page read 2026-09-19; Adyen Docs, Bancontact card, live page read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "primary_not_public": true, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rule.contactless-no-pin-50-eur", "id": "rule.contactless-no-pin-50-eur", "rail": "bancontact", "class": "Rule", "name": "Contactless without PIN up to 50 euro", "statement": "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.", "rests_on": "rule", "facet": "limits", "parameters": { "limit": { "amount": 50, "currency": "EUR", "per": "entry", "text": "no PIN for a contactless tap up to 50 euro" } }, "relations": [ { "type": "sourced_from", "to": "bancontact:src.bancontact-card-page", "section": "contactless and Apple Pay sections", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.card-issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.card-in-store", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Bancontact card page, read 2026-09-19. One source, the operator's consumer page; the scheme rule is not public and a second independent source is needed before corroboration. Issuers may set lower thresholds [Unverified].", "confidence": "medium" }, "currency": { "effective_since": "2026-09-19", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the operator's undated consumer page. The date is the day the page was read, not the day the 50 euro threshold began, which was not found.", "source_edition": "bancontact.com, Bancontact card (consumer page), live page read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "primary_not_public": true, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rule.dispute-evidence-signed-succeeded", "id": "rule.dispute-evidence-signed-succeeded", "rail": "bancontact", "class": "Rule", "name": "In a dispute, Bancontact Company answers only against a signed SUCCEEDED", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 7.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.bancontact-company", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.pro-wero", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C article 7.3, read 2026-09-19, stated in Orca's own words.", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms BC accepts liability in a dispute only against a digitally signed SUCCEEDED confirmation, or the Merchant Portal status for a sticker or fixed QR code, article 7.3." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rule.individual-payout-invoice", "id": "rule.individual-payout-invoice", "rail": "bancontact", "class": "Rule", "name": "Individual payouts, and the invoice product", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "bancontact:src.portal-payouts-052025", "section": "Payouts; Individual Payout Remittance Information", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.bancontact-company", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.pro-wero", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Payouts guide, read 2026-09-19. That an individual payout goes out at once is the guide's word; the transfer's own speed follows the payout bank [Inference].", "confidence": "high" }, "currency": { "effective_since": "Unknown: the guide gives no effective date", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Bancontact Pro developer portal guide versioned 052025. The guide gives no effective date; the version suffix suggests May 2025 [Inference].", "source_edition": "Bancontact Pro Developer Portal, Payouts, Bulking and Remittance Information, guide version 052025, read from the page data on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.portal-payouts-052025", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms individual payouts credit each SUCCEEDED transaction at once, that bulked payouts are the default except for the invoice product which supports only individual payouts, and that individual payout for the invoice product typically needs structured remittance in the reference." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rule.issuer-approves", "id": "rule.issuer-approves", "rail": "bancontact", "class": "Rule", "name": "The issuer or payer's bank decides whether a payment goes through", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 7.2.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.portal-errors-statuses-052025", "section": "Payment Statuses, AUTHORIZATION_FAILED", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.app-terms-8-0", "section": "article 6.2.4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.scf-response-2014", "section": "question 16", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.card-issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.payer-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.card-in-store", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.card-online", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2p", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.pro-wero", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C article 7.2.1; errors and statuses guide; App T&C article 6.2.4; SCF response question 16 (May 2014); read 2026-09-19. The issuer's own decision rules are not public.", "confidence": "medium" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19; Bancontact Pro Developer Portal, API Errors, Statuses, and Responses, guide version 052025, read from the page data on 2026-09-19; Bancontact Pay App Terms and Conditions, version 8.0, applicable from 2026-03-01, English PDF of 12 pages, read in full 2026-09-19; Response of the Bancontact/Mister Cash card scheme to the Eurosystem questionnaire on SEPA compliance of card schemes, Bancontact SA/NV, May 2014, English PDF of 13 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms only payments the payer bank approves are credited to the merchant, article 7.2.1." }, { "source": "bancontact:src.portal-errors-statuses-052025", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms AUTHORIZATION_FAILED as a final status for a transaction that failed bank-side validation, for example insufficient funds or card limits." }, { "source": "bancontact:src.app-terms-8-0", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms Bancontact Company makes no representation that a card issuer will approve or honour a Mobile Bancontact Transaction, article 6.2.4." }, { "source": "bancontact:src.scf-response-2014", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms all transactions are authorised by the issuer, either online or off-line by the chip, question 16." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rule.liability-cap-twelve-months-fees", "id": "rule.liability-cap-twelve-months-fees", "rail": "bancontact", "class": "Rule", "name": "Liability between Bancontact Company and the merchant", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 11.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "articles 13.1 to 13.6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.bancontact-company", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.partner", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C article 11.2, articles 13.1 to 13.6, read 2026-09-19, stated in Orca's own words.", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the liability cap of twelve months' fees, the exclusion of indirect loss, the carve-out for wilful misconduct and gross negligence, and the merchant's indemnity duties, article 11.2 and articles 13.1 to 13.6." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rule.merchant-eligibility", "id": "rule.merchant-eligibility", "rail": "bancontact", "class": "Rule", "name": "Who may be a Bancontact Pro merchant", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 2.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 6.1 I, II and VI to IX", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 6.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.bancontact-company", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.pro-wero", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C article 2.2, article 6.1 I, II and VI to IX, article 6.3, read 2026-09-19, stated in Orca's own words.", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the EU shop location and licensing requirement, the know-your-merchant and sanctions checks, the EU IBAN requirement, the own-account duty, and BC's right to decline or suspend on missing information, articles 2.2, 6.1 I, II and VI to IX, and 6.3." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rule.merchant-legal-compliance", "id": "rule.merchant-legal-compliance", "rail": "bancontact", "class": "Rule", "name": "Merchant must follow EU payment, data, interchange and consumer law, and both schemes' rules", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 6.1 III and IV", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.pro-wero", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct-inst:consumer-law", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C article 6.1 III and IV, read 2026-09-19, stated in Orca's own words.", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the duty to comply with PSD2 or the Payment Services Regulation, GDPR, the Interchange Fee Regulation and EU consumer law even outside the EU, and with EPI's and Bancontact's scheme rules, plus the age-restriction duty, article 6.1 III and IV." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rule.no-merchant-minimum-or-maximum", "id": "rule.no-merchant-minimum-or-maximum", "rail": "bancontact", "class": "Rule", "name": "No merchant minimum or maximum under Bancontact Pro", "statement": "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.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 6.6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.bancontact-card-page", "section": "section on small purchases", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.pro-wero", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C article 6.6, read 2026-09-19, stated in Orca's own words.", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the merchant may not indicate a minimum or maximum amount beyond what the payment schemes impose, article 6.6." }, { "source": "bancontact:src.bancontact-card-page", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the consumer page states there is no minimum amount for card payments at the terminal." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rule.no-payer-recall-in-app-terms", "id": "rule.no-payer-recall-in-app-terms", "rail": "bancontact", "class": "Rule", "name": "The app terms give the payer no way to recall a payment", "statement": "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.", "rests_on": "rule", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "bancontact:src.app-terms-8-0", "section": "articles 6.2.1, 6.2.2, 6.2.4 and 21", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.payer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.card-issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2p", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "App T&C articles 6.2.1, 6.2.2, 6.2.4 and 21, read in full 2026-09-19. That no recall exists is [Inference] from its absence; the issuers' terms were not read.", "confidence": "medium" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Bancontact Pay App T&C version 8.0, applicable from 2026-03-01. The date is that version's start date; the provision may be older [Unverified].", "source_edition": "Bancontact Pay App Terms and Conditions, version 8.0, applicable from 2026-03-01, English PDF of 12 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.app-terms-8-0", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms confirmation with the Mobile PIN or biometrics is the payer's electronic signature and the transaction is legally binding, with no recall mechanism described, and that transaction complaints go to the card issuer, articles 6.2.1, 6.2.2, 6.2.4 and 21." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rule.no-surcharge", "id": "rule.no-surcharge", "rail": "bancontact", "class": "Rule", "name": "No surcharge on Bancontact Pro payments", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 6.6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.scf-response-2014", "section": "question 2 a", "note": "Cited only to mark the 2014 position as superseded; not a source for current practice.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.pro-wero", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C article 6.6; SCF response question 2 a (May 2014); read 2026-09-19. That the 2014 position no longer holds for consumer cards rests on the EU surcharge ban under PSD2, which was not read [Inference].", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the merchant shall not surcharge payers for accepting payments through the Acceptance Service, article 6.6." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rule.operator-and-acquirer", "id": "rule.operator-and-acquirer", "rail": "bancontact", "class": "Rule", "name": "Who runs Bancontact Pro and who acquires its Bancontact leg", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 1, definitions of Acquirer, BC and EPI", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 17.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.about-us-page", "section": "company statement on supervision", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.bancontact-company", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.acquirer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.epi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.nbb", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.pro-wero", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C articles 1 and 17.1; About us page; read 2026-09-19. The acquirer named may change in a later edition.", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the definitions of Acquirer, BC and EPI, and BC's right to assign the agreement to a third party, article 1 and article 17.1." }, { "source": "bancontact:src.about-us-page", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms Bancontact Company operates under National Bank of Belgium supervision." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rule.payconiq-url-change", "id": "rule.payconiq-url-change", "rail": "bancontact", "class": "Rule", "name": "New API URLs after the Payconiq brand was retired", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "bancontact:src.portal-errors-statuses-052025", "section": "notice at the top of the guide", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.partner", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.pro-wero", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Developer portal notice carried on the errors, refunds and payouts guides, read 2026-09-19. The new URLs themselves were not read.", "confidence": "high" }, "currency": { "effective_since": "2026-05-11", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the developer portal notice. The date is the production start the notice gives.", "source_edition": "Bancontact Pro Developer Portal, API Errors, Statuses, and Responses, guide version 052025, read from the page data on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.portal-errors-statuses-052025", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the notice at the top of the guide: Payconiq brand decommissioned in Belgium, URL changes rolled out in production from 11/05/2026, needed to keep accepting Bancontact Pay and Wero payments." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rule.payer-bank-credits-segregated-account", "id": "rule.payer-bank-credits-segregated-account", "rail": "bancontact", "class": "Rule", "name": "The payer's bank pays Bancontact Company, which keeps the funds apart", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 7.2.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.portal-payouts-052025", "section": "Remittance Information", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.payer-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.bancontact-company", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.pro-wero", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C article 7.2.1; payouts guide, Remittance Information; read 2026-09-19. For the Bancontact leg, how the card transaction reaches that account (through the acquirer named in the terms) is not described [Unverified].", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms only payer-bank approved transactions are credited, each is credited on BC's account, and BC's own funds are kept separate, article 7.2.1." }, { "source": "bancontact:src.portal-payouts-052025", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the transaction is a credit transfer from the consumer's account to Bancontact Payconiq Company's segregated account." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rule.payment-statuses", "id": "rule.payment-statuses", "rail": "bancontact", "class": "Rule", "name": "Ten payment statuses; a final status never changes", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "bancontact:src.portal-errors-statuses-052025", "section": "Payment Statuses", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.bancontact-company", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.pro-wero", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Errors and statuses guide, read 2026-09-19. The status names are the publisher's, spelling included; the explanations are Orca's.", "confidence": "high" }, "currency": { "effective_since": "Unknown: the guide gives no effective date", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Bancontact Pro developer portal guide versioned 052025. The guide gives no effective date; the version suffix suggests May 2025 [Inference].", "source_edition": "Bancontact Pro Developer Portal, API Errors, Statuses, and Responses, guide version 052025, read from the page data on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.portal-errors-statuses-052025", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the ten status names, their intermediary or final classification, their descriptions, and the rule that a final status never changes." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rule.payout-iban-responsibility", "id": "rule.payout-iban-responsibility", "rail": "bancontact", "class": "Rule", "name": "Wrong or wrongly credited Payout IBAN", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 6.4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 7.2.4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 24.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.bancontact-company", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.pro-wero", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C article 6.4, article 7.2.4, article 24.3, read 2026-09-19, stated in Orca's own words.", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the merchant's ownership guarantee, BC's non-liability for a wrong Payout IBAN, the duty to repay a wrongful credit, and BC's set-off right, articles 6.4, 7.2.4 and 24.3." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rule.refund-api-conditions", "id": "rule.refund-api-conditions", "rail": "bancontact", "class": "Rule", "name": "When a merchant may refund through the API", "statement": "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.", "rests_on": "rule", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 1, definition of Refund", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "articles 9.3.1 to 9.3.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.portal-refunds-052025", "section": "Introduction; Create Refund", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "bancontact:exc.refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.pro-wero", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C articles 1 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 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the definition of Refund and the conditions for using the Refund API: bulked payments, Digital Signature implemented, SUCCEEDED status, created no more than one year prior, article 1 and articles 9.3.1 to 9.3.3." }, { "source": "bancontact:src.portal-refunds-052025", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the createRefund endpoint needs a JSON Web Signature and activation, and the idempotency key rule for retries versus deliberate additional refunds." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "bancontact:exc.refund", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "bancontact:rule.refund-iban-lookup", "id": "rule.refund-iban-lookup", "rail": "bancontact", "class": "Rule", "name": "Looking up the payer's IBAN for a refund", "statement": "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.", "rests_on": "rule", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "bancontact:src.portal-refunds-052025", "section": "Get Refund IBAN", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.pro-wero", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Refunds guide, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "Unknown: the guide gives no effective date", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Bancontact Pro developer portal guide versioned 052025. The guide gives no effective date; the version suffix suggests May 2025 [Inference].", "source_edition": "Bancontact Pro Developer Portal, Refunds, guide version 052025, read from the page data on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.portal-refunds-052025", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the getRefundIban endpoint returns the payer's IBAN for refund processing, validation or audit, handles no money flow, needs only the API key, and is refused for a P2P payment or unavailable debtor details." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rule.refund-netted-from-payout", "id": "rule.refund-netted-from-payout", "rail": "bancontact", "class": "Rule", "name": "Refunds come out of the day's payout and fail on a negative balance", "statement": "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.", "rests_on": "rule", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 9.3.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.portal-refunds-052025", "section": "Introduction", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "bancontact:exc.refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.bancontact-company", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.pro-wero", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C article 9.3.2; refunds guide; read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the running balance per bulking period, the deduction of refunds from the day's payments, and refusal of a refund that would go negative, article 9.3.2." }, { "source": "bancontact:src.portal-refunds-052025", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms successful refunds are deducted from the ongoing settlement payout and refused when funds are insufficient." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "bancontact:exc.refund", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "bancontact:rule.refund-policy-disclosure", "id": "rule.refund-policy-disclosure", "rail": "bancontact", "class": "Rule", "name": "Disclose return, refund and cancellation limits before payment", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 6.1 V", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 6.7", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.pro-wero", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C article 6.1 V, article 6.7, read 2026-09-19, stated in Orca's own words.", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the online-site information duty and the pre-payment disclosure duty for restrictive return, refund or cancellation policies, article 6.1 V and article 6.7." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rule.refusal-and-suspension", "id": "rule.refusal-and-suspension", "rail": "bancontact", "class": "Rule", "name": "When Bancontact Company may refuse or suspend a payment", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "articles 12.1.1 to 12.1.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.bancontact-company", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.pro-wero", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C articles 12.1.1 to 12.1.3, read 2026-09-19, stated in Orca's own words.", "confidence": "medium" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the grounds for refusal or suspension before SUCCEEDED and the notice duty, articles 12.1.1 to 12.1.3." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rule.remittance-information", "id": "rule.remittance-information", "rail": "bancontact", "class": "Rule", "name": "Remittance information on payouts and refunds within 140 characters", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "bancontact:src.portal-payouts-052025", "section": "Remittance Information", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.bancontact-company", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.pro-wero", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Payouts guide, read 2026-09-19; fields named in Orca's own order, without lengths or positions.", "confidence": "high" }, "currency": { "effective_since": "Unknown: the guide gives no effective date", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Bancontact Pro developer portal guide versioned 052025. The guide gives no effective date; the version suffix suggests May 2025 [Inference].", "source_edition": "Bancontact Pro Developer Portal, Payouts, Bulking and Remittance Information, guide version 052025, read from the page data on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.portal-payouts-052025", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the 140-character EPC limit and the field content of bulked payout, individual payout and refund remittance information, and that the fields still use the Payconiq-era name." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rule.representment", "id": "rule.representment", "rail": "bancontact", "class": "Rule", "name": "Representment: Bancontact Company decides, the merchant has 15 days to send evidence", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 1, definition of Representment", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 7.5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "bancontact:exc.wero-chargeback", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.bancontact-company", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.pro-wero", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C articles 1 and 7.5, read 2026-09-19. The terms say 15 days without saying working days; calendar days are [Inference].", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the definition of Representment, that the merchant does not initiate a chargeback or representment, and the 15-day evidence deadline, article 1 and article 7.5." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "bancontact:exc.wero-chargeback", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "bancontact:rule.restricted-activities", "id": "rule.restricted-activities", "rail": "bancontact", "class": "Rule", "name": "Activities that let Bancontact Company refuse or restrict a merchant", "statement": "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.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 6.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.bancontact-company", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.pro-wero", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C article 6.2, read 2026-09-19, grouped in Orca's own order and words; the terms' own list is longer and more specific.", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the restricted activities list and the 30-day notice duty for changed information, article 6.2." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rule.scheme-membership", "id": "rule.scheme-membership", "rail": "bancontact", "class": "Rule", "name": "Card scheme: membership and licences", "statement": "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.", "rests_on": "guidance", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "bancontact:src.scf-response-2014", "section": "questions 11 to 15, 19 a and 21.1", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.legal-specifications-page", "section": "fall-back interchange and service fees", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.bancontact-company", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.card-issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.acquirer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.card-in-store", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.card-online", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2p", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "SCF response questions 11 to 15, 19 a and 21.1 (May 2014); legal specifications page; read 2026-09-19. One scheme-level source; the page shows the fee table as an image, which was not read. A second independent source is needed before corroboration.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the scheme described it as in place when it answered the Eurosystem", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the scheme's May 2014 answer to the Eurosystem, the only scheme-level document the operator publishes. It describes the scheme as it stood in 2014, before PSD2 and the Interchange Fee Regulation; whether it still holds is [Unverified]. The scheme rules are not public, so the record carries primary_not_public and needs two independent sources on different hosts before it can be corroborated.", "source_edition": "Response of the Bancontact/Mister Cash card scheme to the Eurosystem questionnaire on SEPA compliance of card schemes, Bancontact SA/NV, May 2014, English PDF of 13 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "primary_not_public": true, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rule.succeeded-guarantees-payout", "id": "rule.succeeded-guarantees-payout", "rail": "bancontact", "class": "Rule", "name": "SUCCEEDED binds Bancontact Company to pay the merchant", "statement": "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.", "rests_on": "rule", "facet": "finality", "parameters": { "liability_holder": { "role": "bancontact:role.bancontact-company", "condition": "once it has reported the payment as SUCCEEDED, unless regulation forbids the payout or the merchant's bank blocks it", "text": "Bancontact Company owes the merchant the gross amount of a SUCCEEDED payment" } }, "relations": [ { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 7.2.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 12.1.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.bancontact-company", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.pro-wero", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C article 7.2.3, article 12.1.2, read 2026-09-19, stated in Orca's own words.", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the SUCCEEDED payout guarantee, its two exceptions, and that BC can no longer refuse the payment after SUCCEEDED, article 7.2.3 and article 12.1.2." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:rule.unauthorised-claims-outside-chargeback", "id": "rule.unauthorised-claims-outside-chargeback", "rail": "bancontact", "class": "Rule", "name": "A payer's claim of no authorisation is not a Wero chargeback", "statement": "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].", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 8", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.payer-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.pro-wero", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct-inst:consumer-law", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C article 8, read 2026-09-19. Where an unauthorised claim goes instead is [Inference]; no law and no EPI rule was read.", "confidence": "medium" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms article 8 excludes a payer's claim of no authorisation from the Wero chargeback route." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "bancontact:exc.wero-chargeback", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "bancontact:rule.void-hold-168-hours", "id": "rule.void-hold-168-hours", "rail": "bancontact", "class": "Rule", "name": "Void service: funds held up to 168 hours", "statement": "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.", "rests_on": "rule", "facet": "recall", "parameters": { "time_window": { "count": 168, "unit": "hour", "from": "receipt", "text": "168 hours from the payment's creation in Bancontact Company's systems" } }, "relations": [ { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 9.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.portal-errors-statuses-052025", "section": "Payment Statuses, PENDING_MERCHANT_AKNOWLEDGMENT and VOIDED", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "bancontact:exc.void", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.bancontact-company", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.mobile-p2m", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.pro-wero", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C article 9.2; errors and statuses guide; read 2026-09-19. The time_window from value receipt stands for the payment's creation in Bancontact Company's systems, the nearest value the schema offers.", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the 168-hour void hold, and that confirmation, cancellation or time-out resolve it, article 9.2." }, { "source": "bancontact:src.portal-errors-statuses-052025", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms PENDING_MERCHANT_AKNOWLEDGMENT and VOIDED apply only when the void service is active." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "bancontact:exc.void", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "bancontact:rule.wero-chargeback", "id": "rule.wero-chargeback", "rail": "bancontact", "class": "Rule", "name": "Wero payments can be charged back for any dispute except an unauthorised one", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 1, definition of Chargeback", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 7.5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 8", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "bancontact:exc.wero-chargeback", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.payer-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.bancontact-company", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.pro-wero", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct-inst:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C articles 1, 7.5 and 8, read 2026-09-19. The chargeback window and grounds under EPI's scheme rules were not read [Unverified].", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the chargeback definition and process, the netting or negative-balance carry-forward, the chargeback fee, and BC's right to recover chargebacks after termination, article 1 and articles 7.5 and 8." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "bancontact:exc.wero-chargeback", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "bancontact:rule.wero-leg-sepa-instant", "id": "rule.wero-leg-sepa-instant", "rail": "bancontact", "class": "Rule", "name": "The Wero leg is a SEPA instant credit transfer under EPI's scheme", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 1, definitions of Wero, EPI and Acceptance Service", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 6.1 III", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.portal-payouts-052025", "section": "Remittance Information", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.payer-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "bancontact:role.epi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "bancontact:txn.pro-wero", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct-inst:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct-inst:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct-inst:limits", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct-inst:hours", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct-inst:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct-inst:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct-inst:consumer-law", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct-inst:participants", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct-inst:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C articles 1 and 6.1 III; payouts guide; read 2026-09-19. That SCT Inst's scheme rules govern the transfer leg is [Inference] from the definition of Wero; EPI's rules were not read, and whether Wero adds its own limits is [Unverified].", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the definitions of Wero, EPI and Acceptance Service, and the scheme-rules compliance duty for EPI's rules, article 1 and article 6.1 III." }, { "source": "bancontact:src.portal-payouts-052025", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the transaction is a credit transfer from the consumer's account to Bancontact Payconiq Company's segregated account." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:src.about-us-page", "id": "src.about-us-page", "rail": "bancontact", "class": "RuleSource", "name": "Bancontact, About us", "summary": "The operator's company page: the four product brands (Bancontact Pay, the Bancontact card, Bancontact One Click, Bancontact Pro) and the statement that Bancontact Company is a payment institution supervised by the National Bank of Belgium.", "publisher": "Bancontact Company SA/NV", "url": "https://www.bancontact.com/en/about-us", "source_class": "public_primary", "kind": "web_page", "edition": "bancontact.com, About us, live page read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-19 for the bancontact rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "bancontact.com, About us, live page read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "bancontact:role.bancontact-company", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:role.nbb", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.app-cards-and-private-p2p", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.operator-and-acquirer", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "bancontact:src.adyen-bancontact-card", "id": "src.adyen-bancontact-card", "rail": "bancontact", "class": "RuleSource", "name": "Adyen Docs, Bancontact card", "summary": "Adyen's page for accepting the Bancontact card online: like a card payment but with no security code and mandatory 3D Secure, no separate capture, no chargebacks in its feature table, co-badged cards, and recurring payments through the Bancontact Wallet Initiated Program. A processor's description, not a Bancontact rule.", "publisher": "Adyen", "url": "https://docs.adyen.com/payment-methods/bancontact/bancontact-card", "source_class": "secondary", "kind": "web_page", "edition": "Adyen Docs, Bancontact card, live page read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-19 for the bancontact rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "Adyen Docs, Bancontact card, live page read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "bancontact:rule.card-payments-no-chargeback-per-processors", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.card-scheme-authentication", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.co-badged-cards", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:txn.card-online", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "bancontact:src.adyen-co-badged-cards", "id": "src.adyen-co-badged-cards", "rail": "bancontact", "class": "RuleSource", "name": "Adyen Docs, Issues processing co-badged Bancontact cards", "summary": "Adyen's page on Bancontact cards co-badged with Visa Debit, issued by a major Belgian bank from early 2021 in place of Maestro: the shopper can pay in the Bancontact card flow or as a generic card, and should be able to choose the scheme. A processor's description, not a Bancontact rule.", "publisher": "Adyen", "url": "https://docs.adyen.com/payment-methods/bancontact/bancontact-card/co-branded-cards", "source_class": "secondary", "kind": "web_page", "edition": "Adyen Docs, Issues processing co-badged Bancontact cards, live page read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-19 for the bancontact rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "Adyen Docs, Issues processing co-badged Bancontact cards, live page read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "bancontact:rule.co-badged-cards", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "bancontact:src.adyen-docs-bancontact-mobile", "id": "src.adyen-docs-bancontact-mobile", "rail": "bancontact", "class": "RuleSource", "name": "Adyen Docs, Bancontact mobile", "summary": "A public document at docs.adyen.com, created as a RuleSource when bancontact-boleto-validator recorded a check of bancontact:rule.card-payments-no-chargeback-per-processors against it on 2026-09-19. Its publisher, kind and edition are as far as that check identified them.", "publisher": "docs.adyen.com", "url": "https://docs.adyen.com/payment-methods/bancontact/bancontact-mobile", "source_class": "secondary", "kind": "web_page", "edition": "as consulted on 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document at its url, as consulted by bancontact-boleto-validator on 2026-09-19.", "confidence": "low" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by scripts/corroborate.mjs on 2026-09-19. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "as consulted on 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "bancontact:src.app-terms-8-0", "id": "src.app-terms-8-0", "rail": "bancontact", "class": "RuleSource", "name": "Bancontact Pay App Terms and Conditions, version 8.0", "summary": "The operator's terms for the consumer app: what a Mobile Bancontact Transaction is, card registration, Mobile PIN and biometric authorisation, app limits on top of card limits, blocking through Card Stop, and the operator's liability exclusions. The card and the card transactions themselves are governed by each card issuer's terms, not by this document.", "publisher": "Bancontact Company SA/NV", "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", "kind": "pdf_document", "edition": "Bancontact Pay App Terms and Conditions, version 8.0, applicable from 2026-03-01, English PDF of 12 pages, read in full 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-19 for the bancontact rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "Bancontact Pay App Terms and Conditions, version 8.0, applicable from 2026-03-01, English PDF of 12 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "bancontact:rail.bancontact", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:role.bancontact-company", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:role.card-issuer", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:role.payer", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.app-and-card-blocking", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.app-cards-and-private-p2p", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.app-limits-over-card-limits", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.app-operator-liability-limits", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.card-rights-issuer-terms", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.issuer-approves", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.no-payer-recall-in-app-terms", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:txn.mobile-p2m", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:txn.mobile-p2p", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "bancontact:src.bancontact-card-page", "id": "src.bancontact-card-page", "rail": "bancontact", "class": "RuleSource", "name": "Bancontact, Bancontact card", "summary": "The operator's consumer page for the debit card: contactless without PIN up to 50 euro, online payment through the app, a bank app or a card reader, One Click stored credentials and recurring payments, Apple Pay, no minimum amount at the terminal, and blocking through Card Stop.", "publisher": "Bancontact Company SA/NV", "url": "https://www.bancontact.com/en/consumer/bancontact-card", "source_class": "public_primary", "kind": "web_page", "edition": "bancontact.com, Bancontact card (consumer page), live page read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-19 for the bancontact rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "bancontact.com, Bancontact card (consumer page), live page read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "bancontact:rule.app-and-card-blocking", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.contactless-no-pin-50-eur", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.no-merchant-minimum-or-maximum", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:txn.card-in-store", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:txn.card-online", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "bancontact:src.legal-specifications-page", "id": "src.legal-specifications-page", "rail": "bancontact", "class": "RuleSource", "name": "Bancontact, Legal and administrative specifications", "summary": "The operator's page stating that the Bancontact payment system is SEPA compliant, linking the 2014 SEPA compliance answer, and showing its fixed fall-back interchange and service fees as an image.", "publisher": "Bancontact Company SA/NV", "url": "https://www.bancontact.com/en/professional/legal-and-administrative-specifications", "source_class": "public_primary", "kind": "web_page", "edition": "bancontact.com, Legal and administrative specifications, live page read 2026-09-19 (the fee table is an image and was not read)", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-19 for the bancontact rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "bancontact.com, Legal and administrative specifications, live page read 2026-09-19 (the fee table is an image and was not read)", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "bancontact:rule.scheme-membership", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "bancontact:src.merchant-terms-2026-03-01", "id": "src.merchant-terms-2026-03-01", "rail": "bancontact", "class": "RuleSource", "name": "Bancontact Company, General Terms and Conditions, Merchants (version date 2026-03-01)", "summary": "The contract terms under which Bancontact Company lets a merchant accept payments through Bancontact Pro, its acceptance service: definitions (including Wero, Bancontact, Chargeback, Acquirer), prices, integration, merchant requirements and prohibited activities, payout, bulking, chargebacks and representment, void and refund services, refusal and blocking, liability, termination and governing law.", "publisher": "Bancontact Company SA/NV", "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", "kind": "pdf_document", "edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-19 for the bancontact rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "bancontact:rail.bancontact", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:exc.refund", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:exc.void", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:exc.wero-chargeback", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:role.acquirer", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:role.bancontact-company", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:role.epi", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:role.merchant", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:role.nbb", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:role.partner", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:role.payer-bank", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:role.payer", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.acceptance-service-wero-first", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.acceptance-service-wero-first", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.api-keys-and-signatures", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.api-keys-and-signatures", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.bancontact-leg-no-chargeback", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.bancontact-leg-no-chargeback", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.blocking-and-termination", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.blocking-and-termination", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.brand-display-parity", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.bulked-payout-next-working-day", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.bulked-payout-next-working-day", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.dispute-evidence-signed-succeeded", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.issuer-approves", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.liability-cap-twelve-months-fees", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.liability-cap-twelve-months-fees", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.merchant-eligibility", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.merchant-eligibility", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.merchant-eligibility", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.merchant-legal-compliance", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.no-merchant-minimum-or-maximum", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.no-surcharge", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.operator-and-acquirer", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.operator-and-acquirer", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.payer-bank-credits-segregated-account", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.payout-iban-responsibility", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.payout-iban-responsibility", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.payout-iban-responsibility", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.refund-api-conditions", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.refund-api-conditions", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.refund-netted-from-payout", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.refund-policy-disclosure", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.refund-policy-disclosure", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.refusal-and-suspension", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.representment", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.representment", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.restricted-activities", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.succeeded-guarantees-payout", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.succeeded-guarantees-payout", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.unauthorised-claims-outside-chargeback", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.void-hold-168-hours", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.wero-chargeback", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.wero-chargeback", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.wero-chargeback", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.wero-leg-sepa-instant", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.wero-leg-sepa-instant", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:txn.mobile-p2m", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:txn.pro-wero", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "bancontact:src.portal-errors-statuses-052025", "id": "src.portal-errors-statuses-052025", "rail": "bancontact", "class": "RuleSource", "name": "Bancontact Pro Developer Portal, API Errors, Statuses, and Responses (052025)", "summary": "The developer guide listing HTTP status codes, the ten payment statuses (four intermediary, six final) and the thirteen common error codes used across Bancontact's public APIs for payments, refunds and merchant reconciliation, with the error response structure and handling advice. The page also carries the notice of new API URLs after the Payconiq brand was retired.", "publisher": "Bancontact Company SA/NV", "url": "https://docs.bancontactpro.com/guides/general/errorsandstatuses052025", "source_class": "authoritative_primary", "kind": "web_page", "edition": "Bancontact Pro Developer Portal, API Errors, Statuses, and Responses, guide version 052025, read from the page data on 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-19 for the bancontact rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "Bancontact Pro Developer Portal, API Errors, Statuses, and Responses, guide version 052025, read from the page data on 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "bancontact:exc.void", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.api-errors", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.issuer-approves", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.payconiq-url-change", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.payment-statuses", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.void-hold-168-hours", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "bancontact:src.portal-payouts-052025", "id": "src.portal-payouts-052025", "rail": "bancontact", "class": "RuleSource", "name": "Bancontact Pro Developer Portal, Payouts, Bulking and Remittance Information (052025)", "summary": "The developer guide for how merchants are paid: SEPA credit transfer payouts, bulked (next working day) or individual, bulking by closing time and Bulk ID, weekend timing, the segregated account, and the remittance information of individual, bulked and refund transfers within 140 characters.", "publisher": "Bancontact Company SA/NV", "url": "https://docs.bancontactpro.com/guides/general/payoutremittance052025", "source_class": "authoritative_primary", "kind": "web_page", "edition": "Bancontact Pro Developer Portal, Payouts, Bulking and Remittance Information, guide version 052025, read from the page data on 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-19 for the bancontact rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "Bancontact Pro Developer Portal, Payouts, Bulking and Remittance Information, guide version 052025, read from the page data on 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "bancontact:role.bancontact-company", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.bulk-closing-time", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.bulked-payout-next-working-day", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.individual-payout-invoice", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.payer-bank-credits-segregated-account", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.remittance-information", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.wero-leg-sepa-instant", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:txn.pro-wero", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "bancontact:src.portal-refunds-052025", "id": "src.portal-refunds-052025", "rail": "bancontact", "class": "RuleSource", "name": "Bancontact Pro Developer Portal, Refunds (052025)", "summary": "The developer guide for the Refund API: full or partial refunds of SUCCEEDED payments, idempotency keys, deduction from the bulk payout, refusal on insufficient funds, the refund IBAN lookup and its errors, and activation of the signed create refund endpoint.", "publisher": "Bancontact Company SA/NV", "url": "https://docs.bancontactpro.com/guides/general/refunds052025", "source_class": "authoritative_primary", "kind": "web_page", "edition": "Bancontact Pro Developer Portal, Refunds, guide version 052025, read from the page data on 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-19 for the bancontact rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "Bancontact Pro Developer Portal, Refunds, guide version 052025, read from the page data on 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "bancontact:exc.refund", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.api-errors", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.api-keys-and-signatures", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.refund-api-conditions", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.refund-iban-lookup", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.refund-netted-from-payout", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:txn.mobile-p2p", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "bancontact:src.scf-response-2014", "id": "src.scf-response-2014", "rail": "bancontact", "class": "RuleSource", "name": "Response of the Bancontact/Mister Cash Card Scheme to the Eurosystem questionnaire on SEPA compliance of card schemes (May 2014)", "summary": "The card scheme's own yes or no answers, with short explanations, to the Eurosystem's SEPA Cards Framework questions: territoriality, surcharging as it stood in 2014, certification, separation of scheme and processing, membership and licences, issuer authorisation, fees, fraud measures and the magnetic stripe. It describes the scheme rules; it is not the rulebook, which is not public.", "publisher": "Bancontact SA/NV", "url": "https://assets-us-01.kc-usercontent.com:443/0d76cd9b-cf9d-007c-62ee-e50e20111691/bb016082-88a9-42e9-9c43-8671a31d3349/SEPA_EN.pdf", "source_class": "public_primary", "kind": "pdf_document", "edition": "Response of the Bancontact/Mister Cash card scheme to the Eurosystem questionnaire on SEPA compliance of card schemes, Bancontact SA/NV, May 2014, English PDF of 13 pages, read in full 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-19 for the bancontact rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "Response of the Bancontact/Mister Cash card scheme to the Eurosystem questionnaire on SEPA compliance of card schemes, Bancontact SA/NV, May 2014, English PDF of 13 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "bancontact:rail.bancontact", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:role.acquirer", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:role.card-issuer", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:role.merchant", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.card-scheme-authentication", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.card-scheme-processing-model", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.issuer-approves", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "bancontact:rule.no-surcharge", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.scheme-membership", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:txn.card-in-store", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:txn.card-online", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "bancontact:src.stripe-bancontact", "id": "src.stripe-bancontact", "rail": "bancontact", "class": "RuleSource", "name": "Stripe Docs, Bancontact payments", "summary": "Stripe's page for accepting Bancontact online: Belgium and EUR, customer-authenticated, no dispute support, refunds and partial refunds (Stripe allows 730 days). A processor's description of its own integration, not a Bancontact rule.", "publisher": "Stripe", "url": "https://docs.stripe.com/payments/bancontact", "source_class": "secondary", "kind": "web_page", "edition": "Stripe Docs, Bancontact payments, live page read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-19 for the bancontact rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "Stripe Docs, Bancontact payments, live page read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "bancontact:rule.card-payments-no-chargeback-per-processors", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "bancontact:src.what-is-bancontact-pro-page", "id": "src.what-is-bancontact-pro-page", "rail": "bancontact", "class": "RuleSource", "name": "Bancontact, What is Bancontact Pro", "summary": "The operator's merchant page presenting Bancontact Pro as one solution to accept both Bancontact and Wero payments through a till, a phone or a QR sticker, supporting the Bancontact Pay app and bank apps.", "publisher": "Bancontact Company SA/NV", "url": "https://www.bancontact.com/en/professional/what-is-bancontact-pro", "source_class": "public_primary", "kind": "web_page", "edition": "bancontact.com, What is Bancontact Pro, live page read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-19 for the bancontact rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "bancontact.com, What is Bancontact Pro, live page read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "bancontact:rule.acceptance-service-wero-first", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "bancontact:txn.card-in-store", "id": "txn.card-in-store", "rail": "bancontact", "class": "TransactionType", "name": "Bancontact card payment at a terminal", "summary": "A debit card payment with a physical or digital Bancontact card at a merchant's terminal, by chip with PIN or contactless, the amount taken from the cardholder's account through the issuer and the acquirer. The operator says contactless needs no PIN up to 50 euro.", "sec_code": null, "directions": [ "debit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "bancontact:src.scf-response-2014", "section": "questions 1.2 a and 23 a", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.bancontact-card-page", "section": "contactless section", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "SCF response questions 1.2 a and 23 a (2014); Bancontact card page; read 2026-09-19. sec_code is null: the scheme has no entry class codes. directions is debit: the payee's side pulls from the cardholder's account through the issuer [Inference].", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the scheme's card present rules are not public", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the scheme's May 2014 answer to the Eurosystem, the only scheme-level document the operator publishes. It describes the scheme as it stood in 2014, before PSD2 and the Interchange Fee Regulation; whether it still holds is [Unverified]. The scheme rules are not public, so the record carries primary_not_public and needs two independent sources on different hosts before it can be corroborated.", "source_edition": "Response of the Bancontact/Mister Cash card scheme to the Eurosystem questionnaire on SEPA compliance of card schemes, Bancontact SA/NV, May 2014, English PDF of 13 pages, read in full 2026-09-19; bancontact.com, Bancontact card (consumer page), live page read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "primary_not_public": true, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "bancontact:rule.card-rights-issuer-terms", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.card-scheme-authentication", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.card-scheme-processing-model", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.co-badged-cards", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.contactless-no-pin-50-eur", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.issuer-approves", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.scheme-membership", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "bancontact:txn.card-online", "id": "txn.card-online", "rail": "bancontact", "class": "TransactionType", "name": "Bancontact card payment online", "summary": "A card not present payment with a Bancontact card on a website or in an app, authenticated strongly: through the Bancontact Pay app, a bank app or a card reader. Processors describe it as a card payment with no security code and mandatory 3D Secure. Bancontact One Click stores the card credentials for repeat and recurring payments; its rules were not read.", "sec_code": null, "directions": [ "debit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "bancontact:src.bancontact-card-page", "section": "online shopping and recurring payment sections", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.adyen-bancontact-card", "section": "introduction", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.scf-response-2014", "section": "question 23 a", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Bancontact card page; Adyen Bancontact card page; SCF response question 23 a (2014); read 2026-09-19. sec_code is null.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the scheme's card not present rules are not public", "effective_to": null, "effective_note": "Drafted 2026-09-19 from processors' documentation pages, which describe their own integrations and carry no date. The Bancontact scheme rules are not public, so the record carries primary_not_public and needs two independent sources on different hosts before it can be corroborated.", "source_edition": "bancontact.com, Bancontact card (consumer page), live page read 2026-09-19; Adyen Docs, Bancontact card, live page read 2026-09-19; Response of the Bancontact/Mister Cash card scheme to the Eurosystem questionnaire on SEPA compliance of card schemes, Bancontact SA/NV, May 2014, English PDF of 13 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "primary_not_public": true, "corroboration": [ { "source": "bancontact:src.bancontact-card-page", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms online payment through the Bancontact Pay app, a bank app or a card reader, and that Bancontact One Click stores card credentials for repeat and recurring payments." }, { "source": "bancontact:src.adyen-bancontact-card", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms a Bancontact card payment online has no security code and needs mandatory 3D Secure, an independent secondary source from a different organisation than the operator." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "bancontact:rule.card-payments-no-chargeback-per-processors", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.card-rights-issuer-terms", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.card-scheme-authentication", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.card-scheme-processing-model", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.co-badged-cards", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.issuer-approves", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.scheme-membership", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "bancontact:txn.mobile-p2m", "id": "txn.mobile-p2m", "rail": "bancontact", "class": "TransactionType", "name": "Mobile Bancontact Transaction, person to merchant", "summary": "A Bancontact card transaction in euro that the payer authenticates in the Bancontact Pay app with a Mobile PIN or biometrics, paid to a merchant that accepts Bancontact cards. It stays a card transaction between issuer and acquirer. Under Bancontact Pro, the Bancontact leg is this type [Inference: the Merchant T&C define Bancontact as a mobile solution using a digitised Bancontact card].", "sec_code": null, "directions": [ "debit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "bancontact:src.app-terms-8-0", "section": "article 2, definition of Mobile Bancontact Transaction; article 6.2.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 1, definitions of Bancontact and Acceptance Service", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "App T&C articles 2 and 6.2.1; Merchant T&C article 1; read 2026-09-19. sec_code is null.", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Bancontact Pay App T&C version 8.0, applicable from 2026-03-01. The date is that version's start date; the provision may be older [Unverified].", "source_edition": "Bancontact Pay App Terms and Conditions, version 8.0, applicable from 2026-03-01, English PDF of 12 pages, read in full 2026-09-19; General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.app-terms-8-0", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the definition of Mobile Bancontact Transaction and P2M as person to merchant, article 2 and article 6.2.1." }, { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the definitions of Bancontact and Acceptance Service, article 1." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "bancontact:rule.acceptance-service-wero-first", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.api-errors", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.api-keys-and-signatures", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.app-and-card-blocking", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.app-cards-and-private-p2p", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.app-limits-over-card-limits", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.app-operator-liability-limits", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.bancontact-leg-no-chargeback", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.blocking-and-termination", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.brand-display-parity", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.bulk-closing-time", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.bulked-payout-next-working-day", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.card-payments-no-chargeback-per-processors", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.card-rights-issuer-terms", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.card-scheme-processing-model", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.dispute-evidence-signed-succeeded", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.individual-payout-invoice", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.issuer-approves", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.merchant-eligibility", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.merchant-legal-compliance", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.no-merchant-minimum-or-maximum", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.no-payer-recall-in-app-terms", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.no-surcharge", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.operator-and-acquirer", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.payconiq-url-change", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.payer-bank-credits-segregated-account", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.payment-statuses", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.payout-iban-responsibility", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.refund-api-conditions", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.refund-iban-lookup", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.refund-netted-from-payout", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.refund-policy-disclosure", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.refusal-and-suspension", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.remittance-information", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.restricted-activities", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.scheme-membership", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.succeeded-guarantees-payout", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.void-hold-168-hours", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "bancontact:txn.mobile-p2p", "id": "txn.mobile-p2p", "rail": "bancontact", "class": "TransactionType", "name": "Mobile Bancontact Transaction, person to person", "summary": "A Bancontact card transaction in euro, authenticated in the app, paid to another individual acting as a consumer. Receiving such payments is allowed only for private purposes, not for a business. The refund IBAN lookup in the Bancontact Pro API does not work for a person to person payment.", "sec_code": null, "directions": [ "debit" ], "account_types": [ "consumer" ], "value": true, "relations": [ { "type": "sourced_from", "to": "bancontact:src.app-terms-8-0", "section": "article 2, definition of Mobile Bancontact Transaction; article 6.1.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.portal-refunds-052025", "section": "Get Refund IBAN, error codes", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "App T&C articles 2 and 6.1.2; refunds guide; read 2026-09-19. sec_code is null.", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Bancontact Pay App T&C version 8.0, applicable from 2026-03-01. The date is that version's start date; the provision may be older [Unverified].", "source_edition": "Bancontact Pay App Terms and Conditions, version 8.0, applicable from 2026-03-01, English PDF of 12 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.app-terms-8-0", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms P2P is person to person for private consumer use only, article 2 and article 6.1.2." }, { "source": "bancontact:src.portal-refunds-052025", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the getRefundIban endpoint returns REFUND_NOT_FOUND or REFUND_NOT_AVAILABLE when the payment is P2P or debtor details are not available." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "bancontact:rule.app-and-card-blocking", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.app-cards-and-private-p2p", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.app-limits-over-card-limits", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.app-operator-liability-limits", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.card-rights-issuer-terms", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.card-scheme-processing-model", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.issuer-approves", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.no-payer-recall-in-app-terms", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.scheme-membership", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "bancontact:txn.pro-wero", "id": "txn.pro-wero", "rail": "bancontact", "class": "TransactionType", "name": "Bancontact Pro payment settled by Wero", "summary": "A payment to a Bancontact Pro merchant that the payer completes with Wero, a mobile solution built on SEPA instant credit transfer under EPI's scheme: the payer's bank sends the money to Bancontact Company's segregated account, and Bancontact Company pays the merchant out. The acceptance service tries Wero first and falls back to Bancontact when Wero is not possible.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "bancontact:src.merchant-terms-2026-03-01", "section": "article 1, definitions of Wero and Acceptance Service; article 7.2.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "bancontact:src.portal-payouts-052025", "section": "Remittance Information", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Merchant T&C articles 1 and 7.2.1; payouts guide; read 2026-09-19. sec_code is null. directions is credit: the payer's bank pushes the transfer.", "confidence": "high" }, "currency": { "effective_since": "2026-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the Merchant T&C with version date 2026-03-01. The date is that edition's version date; the provision may be older, and when it first applied was not traced [Unverified].", "source_edition": "General Terms and Conditions, Merchants (Bancontact Pro Acceptance Service), version date 2026-03-01 (file name 260129), English PDF of 20 pages, read in full 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "bancontact:src.merchant-terms-2026-03-01", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the definitions of Wero and Acceptance Service, and that only payer bank approved transactions are credited, article 1 and article 7.2.1." }, { "source": "bancontact:src.portal-payouts-052025", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms transactions are implemented by a credit transfer from the consumer's account to Bancontact Payconiq Company's segregated account." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "bancontact:rule.acceptance-service-wero-first", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.api-errors", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.api-keys-and-signatures", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.blocking-and-termination", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.brand-display-parity", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.bulk-closing-time", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.bulked-payout-next-working-day", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.dispute-evidence-signed-succeeded", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.individual-payout-invoice", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.issuer-approves", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.merchant-eligibility", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.merchant-legal-compliance", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.no-merchant-minimum-or-maximum", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.no-surcharge", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.operator-and-acquirer", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.payconiq-url-change", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.payer-bank-credits-segregated-account", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.payment-statuses", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.payout-iban-responsibility", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.refund-api-conditions", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.refund-iban-lookup", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.refund-netted-from-payout", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.refund-policy-disclosure", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.refusal-and-suspension", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.remittance-information", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.representment", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.restricted-activities", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.succeeded-guarantees-payout", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.unauthorised-claims-outside-chargeback", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.void-hold-168-hours", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.wero-chargeback", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:rule.wero-leg-sepa-instant", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "bancontact:rule.merchant-legal-compliance", "bancontact:rule.no-surcharge", "bancontact:rule.refund-policy-disclosure", "bancontact:rule.card-rights-issuer-terms", "bancontact:rule.unauthorised-claims-outside-chargeback" ], "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.", "relations": [ { "type": "see_also", "to": "sepa-sct-inst:consumer-law", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "bancontact:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "bancontact:src.merchant-terms-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "bancontact:liability", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "bancontact:rule.issuer-approves", "bancontact:rule.refusal-and-suspension", "bancontact:rule.blocking-and-termination", "bancontact:rule.representment", "bancontact:rule.app-and-card-blocking" ], "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.", "relations": [ { "type": "see_also", "to": "sepa-sct-inst:decision-points", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "bancontact:limits", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "bancontact:src.merchant-terms-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "bancontact:limits", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "bancontact:rule.succeeded-guarantees-payout", "bancontact:rule.bancontact-leg-no-chargeback", "bancontact:rule.card-payments-no-chargeback-per-processors", "bancontact:rule.payment-statuses", "bancontact:rule.wero-leg-sepa-instant", "bancontact:rule.wero-chargeback" ], "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].", "relations": [ { "type": "see_also", "to": "sepa-sct-inst:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "bancontact:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "bancontact:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "bancontact:src.merchant-terms-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "bancontact:return", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "bancontact:rule.bulk-closing-time", "bancontact:rule.bulked-payout-next-working-day", "bancontact:rule.void-hold-168-hours", "bancontact:rule.representment" ], "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].", "relations": [ { "type": "see_also", "to": "sepa-sct-inst:hours", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct:hours", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "bancontact:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "bancontact:src.merchant-terms-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": "bancontact:src.portal-payouts-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "bancontact:settlement", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "bancontact:rule.succeeded-guarantees-payout", "bancontact:rule.dispute-evidence-signed-succeeded", "bancontact:rule.liability-cap-twelve-months-fees", "bancontact:rule.payout-iban-responsibility", "bancontact:rule.app-operator-liability-limits", "bancontact:rule.card-scheme-authentication" ], "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.", "relations": [ { "type": "see_also", "to": "sepa-sct-inst:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "bancontact:consumer-law", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "bancontact:src.merchant-terms-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "bancontact:consumer-law", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "bancontact:rule.app-limits-over-card-limits", "bancontact:rule.contactless-no-pin-50-eur", "bancontact:rule.no-merchant-minimum-or-maximum", "bancontact:rule.restricted-activities", "bancontact:rule.refund-netted-from-payout", "bancontact:rule.wero-leg-sepa-instant" ], "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].", "relations": [ { "type": "see_also", "to": "sepa-sct-inst:limits", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "bancontact:decision-points", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "bancontact:src.app-terms-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": "bancontact:src.bancontact-card-page", "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": "bancontact:src.merchant-terms-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "bancontact:decision-points", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "bancontact:rule.payment-statuses", "bancontact:rule.api-errors", "bancontact:rule.api-keys-and-signatures", "bancontact:rule.remittance-information", "bancontact:rule.payconiq-url-change" ], "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.", "relations": [ { "type": "see_also", "to": "sepa-sct:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "bancontact:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "bancontact:src.portal-errors-statuses-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": "bancontact:src.merchant-terms-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "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.", "rules": [ "bancontact:rule.acceptance-service-wero-first", "bancontact:rule.operator-and-acquirer", "bancontact:rule.merchant-eligibility", "bancontact:rule.scheme-membership", "bancontact:rule.app-cards-and-private-p2p", "bancontact:rule.brand-display-parity", "bancontact:rule.co-badged-cards" ], "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.", "relations": [ { "type": "see_also", "to": "sepa-sct-inst:participants", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:participants", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:participants", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "bancontact:src.merchant-terms-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "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.", "rules": [ "bancontact:rule.void-hold-168-hours", "bancontact:rule.no-payer-recall-in-app-terms", "bancontact:rule.wero-leg-sepa-instant" ], "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].", "relations": [ { "type": "see_also", "to": "sepa-sct-inst:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "bancontact:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "bancontact:src.merchant-terms-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": "bancontact:src.app-terms-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "bancontact:finality", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:refund", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "bancontact:rule.refund-api-conditions", "bancontact:rule.refund-netted-from-payout", "bancontact:rule.refund-iban-lookup", "bancontact:rule.refund-policy-disclosure" ], "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.", "relations": [ { "type": "see_also", "to": "bancontact:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct-inst:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "bancontact:src.merchant-terms-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": "bancontact:src.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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "bancontact:messages", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "bancontact:recall", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "bancontact:rule.bancontact-leg-no-chargeback", "bancontact:rule.card-payments-no-chargeback-per-processors", "bancontact:rule.wero-chargeback", "bancontact:rule.representment", "bancontact:rule.unauthorised-claims-outside-chargeback", "bancontact:rule.co-badged-cards" ], "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.", "relations": [ { "type": "see_also", "to": "sepa-sct-inst:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "bancontact:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "bancontact:src.merchant-terms-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "bancontact:finality", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "bancontact:rule.payer-bank-credits-segregated-account", "bancontact:rule.bulked-payout-next-working-day", "bancontact:rule.individual-payout-invoice", "bancontact:rule.wero-leg-sepa-instant", "bancontact:rule.card-scheme-processing-model" ], "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.", "relations": [ { "type": "see_also", "to": "sepa-sct:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct-inst:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "bancontact:hours", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "bancontact:src.merchant-terms-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": "bancontact:src.portal-payouts-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "bancontact:hours", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "blik:rail.blik", "id": "rail.blik", "class": "Rail", "rail": "blik", "name": "BLIK", "governing_authority": "Polski Standard Płatności S.A. (PSP)", "country": "PL", "currency": "PLN", "operators": [ "Polski Standard Płatności S.A." ], "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" ], "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§1.1; §2; §28.1", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-multi-session-2026-04-15", "section": "cover and §29", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "source_class": null, "effective_status_reason": null, "used_by": [] }, { "uid": "blik:exc.cancellation-correction", "id": "exc.cancellation-correction", "rail": "blik", "class": "Exception", "name": "Cancellation or correction", "summary": "A mobile transaction the issuer already authorised is cancelled by PSP or by the acquirer because of a technical error, or its amount is corrected, including after a complaint. Allowed for 13 months from authorisation.", "money_moves": true, "outcome": "The cancellation or correction flows through BLIK clearing between the participants concerned; the detailed mechanics are in non-public operating procedures [Inference].", "relations": [ { "type": "initiated_by", "to": "blik:role.psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "initiated_by", "to": "blik:role.acquirer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "blik:role.psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "blik:role.acquirer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "blik:rule.cancellation-or-correction-13-months", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§10; §12.4; §12.5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "blik:exc.complaint", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition, §10, §12.4 and §12.5, read 2026-09-19. How a cancellation moves money is not in the public rulebook.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms that PSP or the acquirer may cancel an authorised mobile transaction for a technical error, that a transaction may be cancelled or corrected for 13 months from authorisation, and that complaint amount corrections run through a non-public operating procedure." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:rule.cancellation-or-correction-13-months", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "blik:exc.complaint", "id": "exc.complaint", "rail": "blik", "class": "Exception", "name": "Complaint (reklamacja)", "summary": "An interbank complaint a participant files with PSP, usually on a user's or merchant's claim, through PSP's ticket system. PSP investigates, names the party at fault and the account to pay, and settles doubt. It is not a card chargeback: there are no public reason codes, and a participant that misses the deadline is treated as at fault.", "money_moves": true, "outcome": "If the complaint is upheld the party at fault transfers the claimed amount and bears the complaint fee, and PSP may correct amounts; the outcome does not settle the dispute between user and merchant.", "relations": [ { "type": "initiated_by", "to": "blik:role.issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "initiated_by", "to": "blik:role.acquirer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "blik:role.psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "blik:rule.complaint-ticket-process", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "blik:rule.complaint-fault-pays", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "blik:rule.disputes-over-goods-outside-scheme", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§9; §10", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition, §9 and §10, read 2026-09-19. The deadlines are in Annex 4c, not published.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the interbank complaint process run through PSP's ticket system, that PSP investigates and names the party at fault and the account to pay, that PSP settles doubtful cases, and that missing a response deadline counts as accepting fault; the specific deadlines sit in a non-public annex." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:exc.cancellation-correction", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "blik:mandate.recurring-payment", "type": "disputed_via", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.complaint-fault-pays", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.complaint-ticket-process", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.processor-claims-process", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.user-complains-to-own-bank", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "blik:exc.decline", "id": "exc.decline", "rail": "blik", "class": "Exception", "name": "Decline or rejection", "summary": "A BLIK transaction that does not go ahead: the issuer declines it at authorisation, or PSP's system rejects or halts it first (over the per-transaction limit, flagged by fraud monitoring, a payment to a listed illegal gambling domain, an unknown alias, or a recurring set-up the bank cannot handle). The answer goes back to the acceptance device through the acquirer, or through Mastercard for BLIK-C. The error codes are in the non-public Technical Specification.", "money_moves": false, "outcome": "No settlement order is created and no money moves. The user may try again with a new code; a recurring transaction may first go through the bank's 72 hour retry.", "relations": [ { "type": "initiated_by", "to": "blik:role.issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "initiated_by", "to": "blik:role.psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "blik:role.issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "blik:role.psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "blik:rule.declined-authorisation-never-settles", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "blik:rule.per-transaction-limit-unpublished", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "blik:rule.psp-fraud-and-gambling-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "blik:rule.issuer-decides-authorisation", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "blik:rule.recurring-retry-72-hours", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "blik:rule.recurring-flags", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§11.3 f; §14; §23.1 b; §29.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition, §11.3 f, §14, §23.1 b and §29.2, and the 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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms that a transaction the issuer declines or PSP rejects or halts first, whether over the per-transaction limit, on fraud monitoring, for a listed illegal gambling domain, or an unknown alias, never settles, and that the error codes themselves sit in the non-public Technical Specification." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:rule.declined-authorisation-never-settles", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.issuer-decides-authorisation", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.per-transaction-limit-unpublished", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.psp-fraud-and-gambling-rejection", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.recurring-flags", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.recurring-retry-72-hours", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "blik:mandate.recurring-payment", "id": "mandate.recurring-payment", "rail": "blik", "class": "Mandate", "name": "BLIK recurring payment (Płatność powtarzalna BLIK)", "summary": "The user's standing consent, started at the merchant and confirmed in the banking app, for that merchant to start later BLIK transactions from the user's account: automatically for a fixed amount and frequency (model A), with confirmation each time (model M), or automatically with variable amounts (model O). The user sees and cancels it in the app; it stays with the bank where it was set up.", "form": "electronic: requested at the merchant's checkout, usually with a BLIK code, and confirmed by the user in the issuer's mobile banking app; identified by a PAYID alias of up to 64 characters", "scope": [ "recurring", "standing" ], "relations": [ { "type": "given_by", "to": "blik:role.user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "given_to", "to": "blik:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "authorises", "to": "blik:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "evidenced_by", "to": "blik:rule.recurring-consent-in-banking-app", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "blik:rule.recurring-models", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "blik:rule.recurring-retry-72-hours", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "blik:rule.recurring-flags", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "blik:rule.issuer-decides-authorisation", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "revoked_via", "to": "blik:rule.recurring-cancel-in-banking-app", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "disputed_via", "to": "blik:exc.complaint", "note": "[Inference] No public PSP page describes disputing a recurring charge; the FAQ sends users to their bank, whose route to PSP is the complaint.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK Recurring Payments introduction and model A pages, BLIK FAQ recurring questions, and BLIK rulebook §2 (merchant acting under the user's prior authority), all read 2026-09-19. Mandate has no sourced_from relation in Core v0, so the sources sit here and on the linked Rules.", "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. PSP's change history dates a new form of BLIK recurring payments to December 2024 at one bank; when the current models first applied is [Unverified].", "source_edition": "BLIK Recurring Payments pages (undated) and BLIK FAQ as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.blik-recurring-payments-introduction", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the recurring payment as the user's consent, started at the merchant and confirmed in the banking app, for later recurring transactions in models A (fixed, no confirmation), M (confirmation each time) and O (variable, no confirmation), and that the user can see and cancel every recurring payment in the app." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:role.acquirer", "id": "role.acquirer", "rail": "blik", "class": "Role", "name": "Acquirer (Agent Rozliczeniowy)", "summary": "A participant that connects merchants' acceptance devices (online checkouts, POS terminals, mPOS apps, ATMs) to BLIK: it passes transaction data to PSP and pays the merchant. Despite the Polish name it is not a settlement agent. It codes each merchant with an MCC, may offer BLIK only to merchants that meet PSP's conditions, answers for bad-faith transactions its merchants enter, and may cancel an authorised transaction for a technical error. A secured acquirer settles through an account at a securing issuer.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§2 (definitions of Agent Rozliczeniowy, Agent Zabezpieczany); §3.11; §7.1 i, j; §8.2; §12.4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition, §2, §3.11, §7.1 i and j, §8.2 and §12.4, 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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the acquirer definition, its role connecting merchant acceptance devices to BLIK and passing transaction data to PSP, that it is not a settlement agent despite its Polish name, its duty to code merchants with an MCC and restrict BLIK to lawful merchants not on sanctions lists, its liability for bad faith or criminal transactions its merchants enter, and that a secured acquirer settles through an account at a securing issuer." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:exc.cancellation-correction", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "blik:exc.cancellation-correction", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "blik:exc.complaint", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.authorisation-flows", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.bad-faith-and-crime-liability", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.cancellation-or-correction-13-months", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.complaint-alert-threshold", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.complaint-fault-pays", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.complaint-ticket-process", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.disputes-over-goods-outside-scheme", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.downtime-notice", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.issuer-decides-authorisation", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.message-standards-technical-specification", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.order-entry-and-irrevocable-authorisation", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.participant-duties", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.participation-eligibility", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.per-transaction-limit-unpublished", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.recurring-flags", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.refund-to-user", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.security-deposits", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.sessions-multi-session-edition", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.sessions-single-session-edition", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.settlement-entity", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "blik:role.institutional-user", "id": "role.institutional-user", "rail": "blik", "class": "Role", "name": "Institutional user (Użytkownik Instytucjonalny)", "summary": "A legal person, or an organisational unit the law gives legal capacity, that uses the BLIK functions the Technical Specification opens to such users under an agreement with an issuer, for example sending phone transfers from a company system or obtaining codes outside a mobile app.", "kind": "party", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§2 (definition of Użytkownik Instytucjonalny); §11.3 a; §23.1 a", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition, §2, §11.3 a and §23.1 a, 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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the institutional user definition as a legal person or entity with legal capacity using BLIK functionality under an agreement with an issuer, and its role in placing P2P transfer orders and receiving error responses on a missing alias." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:role.issuer", "id": "role.issuer", "rail": "blik", "class": "Role", "name": "Issuer (Wydawca)", "summary": "A participant that offers BLIK to users in its mobile app or another function using BLIK codes. It authenticates users, obtains and registers codes and mobile accounts with PSP, authorises or declines every transaction, pays for what it authorises through the BLIK system, holds settlement liquidity on its NBP account (unless it is an indirect participant settling through another issuer), reports unauthorised transactions to PSP, and jointly guarantees settlement with the other issuers. Variants: a securing issuer holds accounts for secured acquirers and funds their settlement; an indirect participant settles through a direct one.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§2 (definitions of Wydawca, Wydawca Zabezpieczający, Uczestnik pośredni); §7.1 k to n; §7.2; §31.12", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition, §2, §7.1 k to n, §7.2 and §31.12, 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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the issuer definition and duties: authenticating users, obtaining and registering codes and mobile accounts, authorising or declining transactions, holding settlement liquidity on its NBP account unless an indirect participant, reporting unauthorised transactions, and the securing issuer and indirect participant variants." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:exc.complaint", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "blik:exc.decline", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "blik:exc.decline", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.authorisation-flows", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.bad-faith-and-crime-liability", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.blik-c-mastercard-position", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.complaint-alert-threshold", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.complaint-fault-pays", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.complaint-ticket-process", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.declined-authorisation-never-settles", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.disputes-over-goods-outside-scheme", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.downtime-notice", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.express-elixir-p2p-limit", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.issuer-decides-authorisation", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.issuer-is-users-payment-service-provider", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.issuer-set-limits", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.message-standards-technical-specification", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.order-entry-and-irrevocable-authorisation", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.p2p-alias-lookup", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.p2p-express-elixir-irrevocable", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.p2p-request-requester-credited-on-acceptance", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.participant-duties", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.participation-eligibility", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.pin-above-50-pln", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.recurring-cancel-in-banking-app", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.recurring-consent-in-banking-app", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.recurring-models", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.recurring-retry-72-hours", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.security-deposits", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.sessions-multi-session-edition", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.sessions-single-session-edition", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.settlement-entity", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.settlement-guarantee", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.settlement-order-irrevocable", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.sorbnet3-settlement-run", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.unauthorised-transaction-reporting", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.user-complains-to-own-bank", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "blik:role.mastercard-cooperating-scheme", "id": "role.mastercard-cooperating-scheme", "rail": "blik", "class": "Role", "name": "Mastercard, the Cooperating Scheme (Schemat Współpracujący)", "summary": "The card scheme run by Mastercard Europe SA, notified to NBP, that works with PSP on contactless BLIK (BLIK-C). Its tokenisation system (MDES) and MCBP technology carry the BLIK-C token; it routes BLIK-C authorisations between the terminal's acquirer and PSP, and it takes part in BLIK clearing and settlement as a party with its own position.", "kind": "operator", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§2 (definitions of Mastercard, Schemat Współpracujący, MCBP, System Tokenizacyjny); §11.6; §29.13; §31.7", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:participants", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition, §2, §11.6, §29.13 and §31.7, 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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms Mastercard Europe SA as the Cooperating Scheme notified to NBP, its MDES tokenisation and MCBP technology carrying BLIK-C, its role routing BLIK-C authorisations between acquirer and PSP, and its own settlement position in BLIK clearing." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:rule.authorisation-flows", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.blik-c-acceptance", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.blik-c-mastercard-position", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "blik:role.merchant", "id": "role.merchant", "rail": "blik", "class": "Role", "name": "Merchant or acceptant (Akceptant)", "summary": "Whoever accepts BLIK through an acceptance device: a business taking BLIK for its own goods and services or for sellers on its marketplace, a business that starts BLIK transactions under an authority the user gave it earlier (the basis of recurring payments), a registered non-profit foundation or association taking payments through BLIK, or a public body taking taxes and fees. Disputes about goods and services are between the merchant and the user.", "kind": "party", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§2 (definitions of Akceptant, Urządzenie Akceptujące, Platforma Handlowa); §8.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition, §2 and §8.1, 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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the merchant or acceptant definition covering a business taking BLIK for its own goods or a marketplace, a business acting under a user's prior authority (the recurring payment basis), a registered non-profit foundation or association, and a public body taking taxes and fees, and that goods and services disputes run directly between merchant and user." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:mandate.recurring-payment", "type": "given_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.recurring-consent-in-banking-app", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.recurring-flags", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.recurring-models", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.recurring-retry-72-hours", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.refund-to-user", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "blik:role.nbp", "id": "role.nbp", "rail": "blik", "class": "Role", "name": "Narodowy Bank Polski (NBP)", "summary": "Poland's central bank. Its President authorised the BLIK payment system; it runs SORBNET3, where BLIK settles through PSP's auxiliary account; issuers hold their settlement accounts with it; PSP tells it about blocked accounts, guarantee runs, bilateral fallback settlement and decisions on participants. PSP's change history says NBP classed BLIK as a significant retail payment system in 2023.", "kind": "authority", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§2 (definitions of System BLIK, SORBNET3, Rachunek Pomocniczy PSP); §18.1; §19.4; §24.4; §31.11; §31.14", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "blik:src.blik-change-history", "section": "2023 entries", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition, §2, §18.1, §19.4, §24.4, §31.11 and §31.14, and the BLIK change history page, read 2026-09-19. NBP's own pages were not read (bot challenge).", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms NBP as the authority that licensed the BLIK payment system, runs SORBNET3 where BLIK settles through PSP's auxiliary account, holds issuer settlement accounts, and receives PSP's reports on blocked accounts, guarantee runs, bilateral fallback settlement and participant decisions." }, { "source": "blik:src.blik-change-history", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms that in March 2023 NBP classified BLIK into the group of significant retail payment systems, matching the record's claim of a 2023 NBP classification." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:rule.sorbnet3-settlement-run", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.suspension-and-exclusion", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "blik:role.psp", "id": "role.psp", "rail": "blik", "class": "Role", "name": "Polski Standard Płatności S.A. (PSP), operator", "summary": "The Warsaw company that runs both the BLIK payment scheme (as a payment organisation under the Payment Services Act) and the BLIK payment system (as system operator under the Settlement Finality Act, on NBP authorisation D/III/SP/2014). It writes the rulebook and technical standards, admits participants, generates and registers codes, keeps the mobile account base, routes authorisations, monitors for fraud, clears and settles, runs complaints, and may block, suspend or exclude participants. In every BLIK document PSP means this company, not a payment service provider.", "kind": "operator", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§1.1; §2 (definitions of PSP, System BLIK); §5; §6; §28.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition, §1.1, §2, §5, §6 and §28.1, 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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms PSP as the company running both the BLIK payment scheme under the Payment Services Act and the BLIK payment system under the Settlement Finality Act on NBP authorisation D/III/SP/2014, and its rulebook, admission, code generation, routing, monitoring, clearing, settlement and complaint duties." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:exc.cancellation-correction", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "blik:exc.cancellation-correction", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "blik:exc.complaint", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "blik:exc.decline", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "blik:exc.decline", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.authorisation-flows", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.blik-c-mastercard-position", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.cancellation-or-correction-13-months", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.complaint-alert-threshold", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.complaint-fault-pays", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.complaint-ticket-process", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.continuous-operation", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.declined-authorisation-never-settles", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.disputes-over-goods-outside-scheme", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.downtime-notice", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.message-standards-technical-specification", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.net-clearing", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.one-time-code-validity", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.p2p-alias-lookup", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.participation-eligibility", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.per-transaction-limit-unpublished", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.psp-fraud-and-gambling-rejection", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.psp-operator-duties", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.recurring-flags", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.rulebook-changes", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.security-deposits", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.sessions-multi-session-edition", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.sessions-single-session-edition", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.settlement-guarantee", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.settlement-order-irrevocable", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.sorbnet3-settlement-run", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.suspension-and-exclusion", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.temporary-block", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.unauthorised-transaction-reporting", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "blik:role.settlement-entity", "id": "role.settlement-entity", "rail": "blik", "class": "Role", "name": "Settlement entity (Podmiot Rozrachunkowy)", "summary": "A SORBNET3 participant that takes part in settling BLIK transactions: for itself as issuer or acquirer, for an acquirer, indirect participant or the Cooperating Scheme, as a securing issuer for a secured acquirer, or, for an acquirer, as a non-participant it names to PSP. After settlement it credits the participant it settles for.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§2 (definition of Podmiot Rozrachunkowy); §4.1 g, h; §31.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition, §2, §4.1 g and h, and §31.2, 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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the settlement entity definition as a SORBNET3 participant settling for itself as issuer or acquirer, for an acquirer or indirect participant or the Cooperating Scheme, as a securing issuer for a secured acquirer, or as a named non-participant, and that it credits the participant it settles for after the run." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:rule.settlement-entity", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.sorbnet3-settlement-run", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "blik:role.user", "id": "role.user", "rail": "blik", "class": "Role", "name": "User (Użytkownik)", "summary": "A natural person who, under an agreement with an issuer, uses that issuer's activated mobile banking app to make BLIK transactions: pays with a code or contactlessly, withdraws or deposits cash, sends phone transfers and transfer requests, and gives recurring payment consents. The issuer, not PSP, is the user's payment service provider.", "kind": "party", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§2 (definition of Użytkownik); §3.11", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition approved 15 April 2026, §2 and §3.11, 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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the user definition as a natural person using an activated mobile banking app under an agreement with an issuer, and that the issuer, not PSP, is the party providing the payment service to the user." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:mandate.recurring-payment", "type": "given_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "blik:rule.authorisation-flows", "id": "rule.authorisation-flows", "rail": "blik", "class": "Rule", "name": "Four ways a BLIK authorisation travels", "statement": "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].", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§7.2 j, l, m; §11.2 to §11.6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "blik:src.adyen-blik", "section": "BLIK OneClick", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.acquirer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.mastercard-cooperating-scheme", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.code-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.cash", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.refund-to-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.blik-c", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition approved 15 April 2026, read in Polish 2026-09-19 and stated in Orca's own words and order, §7.2 j, l and m, and §11.2 to §11.6; Adyen BLIK page for OneClick.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the four authorisation flows in the rulebook's own step order: PSP-generated one-time code, issuer-registered one-time code, standing alias, and BLIK-C token through Mastercard's tokenisation system, with the issuer's accept or reject always returning through PSP to the acceptance device." }, { "source": "blik:src.adyen-blik", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms BLIK OneClick lets a shopper pay without the six digit code after first saving the merchant as a trusted shop in the issuer's app, supporting the record's inference that OneClick uses the alias flow." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:rule.bad-faith-and-crime-liability", "id": "rule.bad-faith-and-crime-liability", "rail": "blik", "class": "Rule", "name": "Who answers for bad-faith, criminal or intruder transactions", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§7.4; §8.2 to §8.4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.acquirer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.code-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.cash", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.refund-to-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.blik-c", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition approved 15 April 2026, read in Polish 2026-09-19 and stated in Orca's own words and order, §7.4 and §8.2 to §8.4.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms that the acquirer answers for bad-faith or criminal transactions it or its merchants enter including third-party intrusions in their systems, that the issuer answers the same way for its users and its own systems or app, that every participant must work to reduce crime exposure, and that a participant answers for its subcontractors as for itself." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:rule.blik-c-acceptance", "id": "rule.blik-c-acceptance", "rail": "blik", "class": "Rule", "name": "Where contactless BLIK is accepted", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§2 (definition of Sieć Akceptacji Transakcji BLIK-C)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "blik:src.blik-faq", "section": "contactless BLIK questions", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.mastercard-cooperating-scheme", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.blik-c", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:participants", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition approved 15 April 2026, read in Polish 2026-09-19 and stated in Orca's own words and order, §2; BLIK FAQ.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the definition of the BLIK-C acceptance network as contactless terminals marked BLIK or Mastercard, in Poland or abroad." }, { "source": "blik:src.blik-faq", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms that any terminal taking Mastercard contactless payments accepts BLIK-C, that the slip may read MASTERCARD CONTACTLESS, that a foreign merchant may offer to charge in złoty with the rate shown on the terminal, and that no payment card is needed, only an Android phone with NFC." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:rule.blik-c-mastercard-position", "id": "rule.blik-c-mastercard-position", "rail": "blik", "class": "Rule", "name": "BLIK-C settles with Mastercard as a party", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§2 (definitions of Rozliczenie, Rozrachunek, Transakcja Mobilna d); §12.2; §29.5; §29.13; §31.7; §31.8", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.mastercard-cooperating-scheme", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.blik-c", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.refund-to-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition approved 15 April 2026, read in Polish 2026-09-19 and stated in Orca's own words and order, §2, §12.2, §29.5, §29.13, §31.7 and §31.8. That the merchant side settles inside Mastercard's scheme is [Inference] from §11.6 and §29.13; the rulebook does not describe the Mastercard leg.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms that for BLIK-C the issuer's payment runs to Mastercard through the BLIK system with its own position in clearing, fees set in Annex 2, credit from PSP's auxiliary account in the same settlement as acquirers, and that a BLIK-C refund clears only after Mastercard reports sending it for clearing in its own scheme." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:rule.cancellation-or-correction-13-months", "id": "rule.cancellation-or-correction-13-months", "rail": "blik", "class": "Rule", "name": "Cancellation or correction within 13 months", "statement": "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.", "rests_on": "rule", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§10; §12.4; §12.5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.acquirer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.code-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.cash", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.refund-to-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.blik-c", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "blik:exc.cancellation-correction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition approved 15 April 2026, read in Polish 2026-09-19 and stated in Orca's own words and order, §10, §12.4 and §12.5. That no user recall exists is [Inference] from §12.1, which makes the authorised order irrevocable.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms that PSP or the acquirer may cancel an authorised mobile transaction for a technical error, and that a mobile transaction can be cancelled or corrected for 13 months from the day it was authorised." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:exc.cancellation-correction", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "blik:rule.complaint-alert-threshold", "id": "rule.complaint-alert-threshold", "rail": "blik", "class": "Rule", "name": "Alert when complaints pass 3 percent", "statement": "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.", "rests_on": "rule", "facet": "liability", "parameters": { "limit": { "rate": 3, "unit": "percent", "measured_over": "the participant's BLIK transactions in the last 30 days, and only when at least 50 complaints", "text": "more than 3 percent of the participant's BLIK transactions over 30 days, at least 50 complaints" } }, "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§20", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.acquirer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.code-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.cash", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.refund-to-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.blik-c", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition approved 15 April 2026, read in Polish 2026-09-19 and stated in Orca's own words and order, §20.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the exact 3 percent and 50 complaint alert threshold over the last 30 days, and the other alert categories: a ready settlement report, a guarantee run from an issuer's shortfall, and other events the Technical Specification lists." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:rule.complaint-fault-pays", "id": "rule.complaint-fault-pays", "rail": "blik", "class": "Rule", "name": "In a complaint the party at fault pays, PSP decides doubt, silence means fault", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§9.5 to §9.7", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.acquirer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.code-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.cash", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.refund-to-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.blik-c", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "blik:exc.complaint", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition approved 15 April 2026, read in Polish 2026-09-19 and stated in Orca's own words and order, §9.5 to §9.7.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms that the party whose breach caused a complaint's claim bears its cost, that PSP tells participants who is at fault and the account to pay, that PSP resolves doubt over responsibility, and that missing the response deadline counts as accepting fault." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:exc.complaint", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "blik:rule.complaint-ticket-process", "id": "rule.complaint-ticket-process", "rail": "blik", "class": "Rule", "name": "Complaints run from participant to PSP through a ticket system", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§6 f, n; §9.1 to §9.4; §9.8; §24.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.acquirer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.code-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.cash", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.refund-to-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.blik-c", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "blik:exc.complaint", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition approved 15 April 2026, read in Polish 2026-09-19 and stated in Orca's own words and order, §6 f and n, §9.1 to §9.4, §9.8 and §24.3. Complaint deadlines are in Annex 4c, not published.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms that complaints run through PSP's ticket system or an agreed fallback channel, that PSP charges a complaint fee from Annex 1 to the party at fault or the filer if nobody was at fault, the added fee arrangement for BLIK-C complaints handled with Mastercard, and the six year retention period." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:exc.complaint", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "blik:rule.continuous-operation", "id": "rule.continuous-operation", "rail": "blik", "class": "Rule", "name": "The scheme runs around the clock", "statement": "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.", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§3.1; §3.3; §15; §31.5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.code-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.cash", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.refund-to-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.blik-c", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.p2p", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.p2p-request", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition approved 15 April 2026, read in Polish 2026-09-19 and stated in Orca's own words and order, §3.1, §3.3, §15 and §31.5.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the scheme runs every day around the clock apart from planned technical breaks, that users may initiate transactions whenever the scheme runs, that PSP's system time governs registration, and that settlement itself runs only on business days." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:rule.declined-authorisation-never-settles", "id": "rule.declined-authorisation-never-settles", "rail": "blik", "class": "Rule", "name": "A declined transaction never settles", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§11.3 f; §14; §29.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.code-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.cash", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.refund-to-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.blik-c", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "blik:exc.decline", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition approved 15 April 2026, read in Polish 2026-09-19 and stated in Orca's own words and order, §11.3 f, §14 and §29.2. That no return message exists is [Inference] from the rulebook, which names none.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms that a settlement order exists only once PSP registers a positive issuer authorisation, so a declined or pre-authorisation-rejected transaction never enters clearing; the rulebook names no return message for a settled payment." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:exc.decline", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "blik:rule.disputes-over-goods-outside-scheme", "id": "rule.disputes-over-goods-outside-scheme", "rail": "blik", "class": "Rule", "name": "Goods and services disputes stay between user and merchant", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§8.1; §9.9", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.acquirer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.code-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.cash", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.refund-to-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.blik-c", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition approved 15 April 2026, read in Polish 2026-09-19 and stated in Orca's own words and order, §8.1 and §9.9.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms that PSP and each participant answer only for their own breach of the participation agreement or rulebook, not for whether the merchant delivered as agreed, and that a complaint outcome does not prove the user took part in or benefited from the transaction." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:exc.complaint", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "blik:rule.downtime-notice", "id": "rule.downtime-notice", "rail": "blik", "class": "Rule", "name": "Notice of planned breaks and failures", "statement": "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.", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§6 g, h; §7.1 d, e", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.acquirer", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition approved 15 April 2026, read in Polish 2026-09-19 and stated in Orca's own words and order, §6 g and h, and §7.1 d and e.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms PSP must announce planned technical unavailability at least five days ahead and report failures without delay, and that participants owe PSP the same five days' notice of planned maintenance and prompt word on failures." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:rule.express-elixir-p2p-limit", "id": "rule.express-elixir-p2p-limit", "rail": "blik", "class": "Rule", "name": "Phone transfers over Express Elixir: 100,000 PLN per transfer", "statement": "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.", "rests_on": "rule", "facet": "limits", "parameters": { "limit": { "amount": 100000, "currency": "PLN", "per": "entry", "text": "100,000 PLN per MP2P order in Express Elixir" } }, "relations": [ { "type": "sourced_from", "to": "blik:src.kir-express-elixir-rulebook-1-91", "section": "definitions 14, 15 and 36", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "blik:src.kir-express-elixir-bank-page", "section": "limits paragraph", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.p2p", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.p2p-request", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Express Elixir rulebook version 1.91, definitions 14, 15 and 36, and KIR's Express Elixir page, read 2026-09-19. Applies only to the Express Elixir leg; a phone transfer booked inside one bank or settled in the BLIK system is not bound by it [Inference].", "confidence": "high" }, "currency": { "effective_since": "2026-02-01", "effective_to": null, "effective_note": "The date is when Express Elixir rulebook version 1.91 came into force; the limit may be older [Unverified].", "source_edition": "Regulamin systemu Express Elixir version 1.91, in force 1 February 2026, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.kir-express-elixir-rulebook-1-91", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms definition 36, the system transaction limit of 100,000 PLN for RTTR, RTSP and MP2P payment orders including phone transfers, and definition 14, that each institution's own transaction limit for those codes may not exceed that systemwide ceiling." }, { "source": "blik:src.kir-express-elixir-bank-page", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms independently on KIR's bank-facing page that Express Elixir's highest transaction limit is up to 100,000 PLN for a standard transfer (250,000 PLN for payments to customs and tax authorities)." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:rule.issuer-decides-authorisation", "id": "rule.issuer-decides-authorisation", "rail": "blik", "class": "Rule", "name": "The issuer decides; an acquirer's no-confirmation hint is only advice", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§11.3 e; §11.7", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.acquirer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.code-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.cash", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.refund-to-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.blik-c", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "blik:exc.decline", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition approved 15 April 2026, read in Polish 2026-09-19 and stated in Orca's own words and order, §11.3 e and §11.7.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms that whether a transaction goes ahead is the issuer's decision, that PSP may let an acquirer send issuers a no-confirmation recommendation, that the issuer may ignore it, and that the acquirer using it must apply measures against unauthorised transactions." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:exc.decline", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "blik:mandate.recurring-payment", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "blik:rule.issuer-is-users-payment-service-provider", "id": "rule.issuer-is-users-payment-service-provider", "rail": "blik", "class": "Rule", "name": "The issuer is the user's payment service provider", "statement": "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].", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§1.1; §3.11; §28.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.code-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.cash", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.refund-to-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.blik-c", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.p2p", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.p2p-request", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:consumer-law", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition approved 15 April 2026, read in Polish 2026-09-19 and stated in Orca's own words and order, §1.1, §3.11 and §28.1. The Payment Services Act was not read.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms BLIK as a payment scheme under the Payment Services Act and a payment system under the Settlement Finality Act, both run by PSP, and that the issuer provides the payment service to the user while the acquirer only intermediates; the Acts themselves were not read." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:rule.issuer-set-limits", "id": "rule.issuer-set-limits", "rail": "blik", "class": "Rule", "name": "Each bank sets its users' BLIK limits", "statement": "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.", "rests_on": "guidance", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "blik:src.blik-faq", "section": "whether BLIK works the same in every bank; contactless limits; recurring payment limits", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.code-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.cash", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.refund-to-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.blik-c", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.p2p", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.p2p-request", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK FAQ, read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-19", "effective_to": null, "effective_note": "The date is the day PSP's FAQ was read; the practice is older [Unverified].", "source_edition": "BLIK FAQ as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.blik-faq", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms that BLIK amount and count limits are set individually by each bank, that contactless limits are checked in the bank's own channels, and that whether recurring transactions count toward those limits depends on the bank." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:rule.message-standards-technical-specification", "id": "rule.message-standards-technical-specification", "rail": "blik", "class": "Rule", "name": "Message formats and error codes live in the Technical Specification", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§2 (definition of Specyfikacja Techniczna dla Uczestników); §5.1 g, h, m; §6 b, c; §22; list of annexes", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.acquirer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.code-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.cash", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.refund-to-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.blik-c", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.p2p", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.p2p-request", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition approved 15 April 2026, read in Polish 2026-09-19 and stated in Orca's own words and order, §2, §5.1 g, h and m, §6 b and c, §22 and the list of annexes.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms that PSP sets technical and communication standards, checks transactions against the Technical Specification for Participants and notifies non-conforming participants, and that message formats, error codes, code validity and the transaction limit sit in that non-public Annex 3." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:rule.net-clearing", "id": "rule.net-clearing", "rail": "blik", "class": "Rule", "name": "Net clearing of BLIK transactions, fees included", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§3.4; §11.1; §16.2; §29.5; §29.8; §29.9; §31.7", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-multi-session-2026-04-15", "section": "§16.2; §29.5; §29.9", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.code-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.cash", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.refund-to-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.blik-c", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition approved 15 April 2026, read in Polish 2026-09-19 and stated in Orca's own words and order, §3.4, §11.1, §16.2, §29.5, §29.8, §29.9 and §31.7; multi-session edition §16.2, §29.5 and §29.9 compared.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms net clearing with fees from Annex 2, first in first out order handling, and the single-session edition's business day wording tying clearing runs and settlement files to each business day." }, { "source": "blik:src.psp-blik-rulebook-multi-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms that the multi-session edition drops the business day wording from the corresponding sentences of sections 16.2, 29.5 and 29.9, moving the timing into the session timetable instead." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:rule.one-time-code-validity", "id": "rule.one-time-code-validity", "rail": "blik", "class": "Rule", "name": "How long a one-time BLIK code lives", "statement": "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.", "rests_on": "guidance", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§2 (definition of Kod Jednorazowy); §6 i", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "blik:src.blik-faq", "section": "is BLIK safe", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "blik:src.stripe-blik", "section": "overview", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "blik:src.adyen-blik", "section": "shopper flow, BLIK with code", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.code-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.cash", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook §2 and §6 i; BLIK FAQ; Stripe and Adyen BLIK pages; all read 2026-09-19. The 2 minute figure is PSP's public statement, not rule text.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "BLIK rulebook single-session edition approved 15 April 2026; BLIK FAQ, Stripe and Adyen pages as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the rulebook leaves a one-time code's validity period to the non-public Technical Specification, and that PSP generates and manages codes centrally, each serving one transaction only." }, { "source": "blik:src.blik-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 only 2 minutes." }, { "source": "blik:src.stripe-blik", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms Stripe's statement that the BLIK code is valid for 2 minutes." }, { "source": "blik:src.adyen-blik", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms Adyen's statement that the code expires after 120 seconds, matching the record's 2 minute figure stated as seconds." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:rule.order-entry-and-irrevocable-authorisation", "id": "rule.order-entry-and-irrevocable-authorisation", "rail": "blik", "class": "Rule", "name": "When a BLIK order is in and when it can no longer be withdrawn", "statement": "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.", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§12.1 to §12.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.acquirer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.code-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.cash", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.refund-to-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.blik-c", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition approved 15 April 2026, read in Polish 2026-09-19 and stated in Orca's own words and order, §12.1 to §12.3. The multi-session edition's §12 matches.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms that an order counts as entered once the code and transaction data reach PSP, that issuer authorisation is irrevocable from that moment, that authorising a transaction going to clearing commits the issuer to pay the acquirer or Mastercard, and that authorisation decisions must be durably recorded." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:rule.p2p-alias-lookup", "id": "rule.p2p-alias-lookup", "rail": "blik", "class": "Rule", "name": "How a phone transfer finds the payee", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§3.13; §23.1 to §23.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "blik:src.kir-express-elixir-rulebook-1-91", "section": "definition 15", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.p2p", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.p2p-request", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition approved 15 April 2026, read in Polish 2026-09-19 and stated in Orca's own words and order, §3.13 and §23; Express Elixir rulebook 1.91, definition 15.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the alias lookup steps for a phone transfer and a transfer request in the rulebook's own order: PSP resolving the alias to an account, the error returned on a missing alias, and the internal, Express Elixir or BLIK-system routing choice." }, { "source": "blik:src.kir-express-elixir-rulebook-1-91", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms definition 15 (MP2P) as the payment order code identifying a mobile instant transfer where the payee's account number is determined using the Alias database, matching the record's description of MP2P." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:rule.p2p-express-elixir-irrevocable", "id": "rule.p2p-express-elixir-irrevocable", "rail": "blik", "class": "Rule", "name": "Phone transfers over Express Elixir: irrevocable once entered", "statement": "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.", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "blik:src.kir-express-elixir-rulebook-1-91", "section": "§18.1, §18.2, §18.6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§23.1 c; §23.2 d", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.p2p", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.p2p-request", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Express Elixir rulebook version 1.91 (in force 1 February 2026), §18, and BLIK rulebook §23, 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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin systemu Express Elixir version 1.91, in force 1 February 2026, read 2026-09-19; BLIK rulebook single-session edition approved 15 April 2026 for §23", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.kir-express-elixir-rulebook-1-91", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms in sections 18.1, 18.2 and 18.6 that a payment order is entered once registered on KIR's designated computer, cannot be revoked from that moment, and that the receiving institution's authorisation is an irrevocable commitment to credit the payee immediately once it receives the settlement information." }, { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms that a phone transfer or accepted transfer request may be routed through internal settlement, Express Elixir or the BLIK system, so a transfer booked inside one bank or settled in the BLIK system does not pass through Express Elixir." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:rule.p2p-request-requester-credited-on-acceptance", "id": "rule.p2p-request-requester-credited-on-acceptance", "rail": "blik", "class": "Rule", "name": "Transfer request: the requester is credited on acceptance", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§23.2 d", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.p2p", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.p2p-request", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition approved 15 April 2026, read in Polish 2026-09-19 and stated in Orca's own words and order, §23.2 d.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms that the requester's bank credits the requester immediately once PSP reports the payer's acceptance, whichever route settles the transfer, and that BLIK-system settlement of a P2P or P2P-R transaction requires both banks to have implemented the Technical Specification's BLIK-system route." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:rule.participant-duties", "id": "rule.participant-duties", "rail": "blik", "class": "Rule", "name": "What issuers and acquirers must do", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§7.1; §7.2 h to n, q, r; §27.5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.acquirer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.code-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.cash", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.refund-to-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.blik-c", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.p2p", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.p2p-request", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition approved 15 April 2026, read in Polish 2026-09-19 and stated in Orca's own words and order, §7.1, §7.2 h to n, q and r, and §27.5.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the listed issuer and acquirer duties: code and mobile account handling by issuers, MCC tagging and lawful-merchant screening by acquirers, shared duties on technical conformance, audits, anti money laundering law and use of the BLIK mark, and the extra duties on securing issuers, secured acquirers and indirect participants." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:rule.participation-eligibility", "id": "rule.participation-eligibility", "rail": "blik", "class": "Rule", "name": "Who may join BLIK", "statement": "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).", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§3.8; §4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.acquirer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition approved 15 April 2026, read in Polish 2026-09-19 and stated in Orca's own words and order, §3.8 and §4.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the EEA seat and Polish operating entitlement requirement, the listed institution types including Kasa Krajowa, the sanctions and KNF warning list checks, the SORBNET3 and NBP account requirement for issuers unless indirect, and the 18 month go-live deadline." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:rule.per-transaction-limit-unpublished", "id": "rule.per-transaction-limit-unpublished", "rail": "blik", "class": "Rule", "name": "Scheme per-transaction limit: set, but not public", "statement": "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.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§13; §14.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.acquirer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.code-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.cash", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.refund-to-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.blik-c", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "blik:exc.decline", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition approved 15 April 2026, read in Polish 2026-09-19 and stated in Orca's own words and order, §13 and §14.1. The limit itself was not found in any public source.", "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 earliest date Orca can show this provision in force; it did not start then, and when it first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms that a participant may send for authorisation only transactions up to the single-transaction limit the Technical Specification sets, and that PSP's system rejects a larger one with an error code; the figure and code sit in the non-public specification." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:exc.decline", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "blik:rule.pin-above-50-pln", "id": "rule.pin-above-50-pln", "rail": "blik", "class": "Rule", "name": "PIN confirmation above 50 PLN", "statement": "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.", "rests_on": "guidance", "facet": "limits", "parameters": { "limit": { "amount": 50, "currency": "PLN", "per": "entry", "text": "above 50 PLN a PIN is required unless the bank lets the user manage the limit" } }, "relations": [ { "type": "sourced_from", "to": "blik:src.blik-faq", "section": "is BLIK safe", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.code-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.cash", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK FAQ, read 2026-09-19. Not found in the rulebook; whether it is a scheme rule or a common bank practice is [Unverified].", "confidence": "low" }, "currency": { "effective_since": "2026-09-19", "effective_to": null, "effective_note": "The date is the day PSP's FAQ was read; when this practice began is [Unverified].", "source_edition": "BLIK FAQ as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.blik-faq", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms that ATM withdrawals, online payments and in-store payments above 50 PLN must be confirmed with the user's PIN unless the bank lets customers manage that limit themselves; this appears only in the consumer FAQ, not the rulebook." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:rule.processor-claims-process", "id": "rule.processor-claims-process", "rail": "blik", "class": "Rule", "name": "Processors' account of BLIK disputes", "statement": "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].", "rests_on": "practice", "facet": "return", "relations": [ { "type": "sourced_from", "to": "blik:src.stripe-blik", "section": "disputes", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "blik:src.adyen-blik", "section": "feature table", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.code-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "blik:exc.complaint", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Stripe and Adyen BLIK pages, read 2026-09-19. The 12 day deadline is Stripe's, not PSP's.", "confidence": "low" }, "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Stripe and Adyen BLIK pages as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.stripe-blik", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms Stripe's description of BLIK's claims process for suspected fraud, double payments or an amount mismatch, Stripe holding the disputed amount, and the 12 calendar day evidence deadline." }, { "source": "blik:src.adyen-blik", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms Adyen's feature table marks chargebacks with an x (not supported) for BLIK, read directly from the page's emoji markup." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:rule.psp-fraud-and-gambling-rejection", "id": "rule.psp-fraud-and-gambling-rejection", "rail": "blik", "class": "Rule", "name": "PSP rejects on fraud monitoring and blocks illegal gambling domains", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§5.1 q; §5.2; §14.2 to §14.4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.code-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.cash", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.refund-to-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.blik-c", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "blik:exc.decline", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition approved 15 April 2026, read in Polish 2026-09-19 and stated in Orca's own words and order, §5.1 q, §5.2 and §14.2 to §14.4.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms that PSP's system rejects a transaction its fraud monitoring flags before the issuer decides, that it halts and never forwards to the issuer a payment through a domain on Poland's illegal gambling register, that this does not relieve participants of their own gambling-related legal duties, and PSP's parallel monitoring duty under the Payment Services Act." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:exc.decline", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "blik:rule.psp-operator-duties", "id": "rule.psp-operator-duties", "rail": "blik", "class": "Rule", "name": "What PSP must do as operator", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§5.1; §6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition approved 15 April 2026, read in Polish 2026-09-19 and stated in Orca's own words and order, §5.1 and §6.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms PSP's day to day operating duties (codes, mobile accounts, settlement files, complaints, guarantee mechanism), its rule-making duties (security, acceptance, clearing, complaint, technical and communication standards), and its gatekeeper duties (admission, functionality access, banking app approval on uniform criteria, periodic and own audits)." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:rule.recurring-cancel-in-banking-app", "id": "rule.recurring-cancel-in-banking-app", "rail": "blik", "class": "Rule", "name": "Recurring payment: the user sees and cancels it in the bank app", "statement": "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.", "rests_on": "guidance", "relations": [ { "type": "sourced_from", "to": "blik:src.blik-recurring-payments-introduction", "section": "Recurring Payment", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "blik:src.blik-faq", "section": "recurring payment questions", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK Recurring Payments introduction page and 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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "BLIK Recurring Payments introduction page and BLIK FAQ as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.blik-recurring-payments-introduction", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the user can see and cancel all recurring payments in the banking app." }, { "source": "blik:src.blik-faq", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the user cancels a recurring payment by deleting it in the banking app, that deleting it does not always end the service contract with the merchant, and that the recurring payment must be recreated after switching banks." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:mandate.recurring-payment", "type": "revoked_via", "status": "draft", "effective_status": "draft" }, { "from": "blik:state.recurring-payment-active", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "blik:state.recurring-payment-deleted-by-user", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "blik:rule.recurring-consent-in-banking-app", "id": "rule.recurring-consent-in-banking-app", "rail": "blik", "class": "Rule", "name": "Recurring payment: consent started at the merchant, confirmed in the bank app", "statement": "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.", "rests_on": "rule", "relations": [ { "type": "sourced_from", "to": "blik:src.blik-recurring-payments-introduction", "section": "Recurring Payment and Recurring Transaction", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "blik:src.blik-recurring-payments-model-a", "section": "how it works; information displayed in the banking app", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§2 (definition of Akceptant a, second indent)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK Recurring Payments introduction and model A pages, and BLIK rulebook §2, 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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "BLIK Recurring Payments pages (undated) as read 2026-09-19; BLIK rulebook single-session edition approved 15 April 2026 for §2", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.blik-recurring-payments-introduction", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms a recurring payment is the user's consent initiated at the merchant's site or app and confirmed in the banking app, that the recurring transaction is a separate merchant-started event that does not automatically follow from the consent, and that a first charge may be taken at set-up." }, { "source": "blik:src.blik-recurring-payments-model-a", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the merchant selects the BLIK Recurring Payment method and enters a BLIK code to initiate, and that the banking app's authorisation screen displays the merchant name, amount, frequency and expiry." }, { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the rulebook's merchant definition already covers a business that initiates or lets a user initiate a BLIK transaction under authority the user gave it earlier." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:mandate.recurring-payment", "type": "evidenced_by", "status": "draft", "effective_status": "draft" }, { "from": "blik:state.recurring-payment-active", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "blik:rule.recurring-flags", "id": "rule.recurring-flags", "rail": "blik", "class": "Rule", "name": "Recurring payment flags and the one public BLIK error code", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "blik:src.blik-recurring-payments-introduction", "section": "refuseNoPayID mechanism; NODELAY flag", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.acquirer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "blik:exc.decline", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK 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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "BLIK Recurring Payments introduction page (undated) as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.blik-recurring-payments-introduction", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the refuseNoPayId flag rejecting a transaction when the identified bank does not support recurring payments, the zero-amount set-up rejection with error code ER_PAYID_UNHANDLED never reaching the bank, the NODELAY flag skipping the 72 hour retry for models A and O only, and that all acquirers must support both flags." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:exc.decline", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "blik:mandate.recurring-payment", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "blik:rule.recurring-models", "id": "rule.recurring-models", "rail": "blik", "class": "Rule", "name": "Recurring payment models A, M and O", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "blik:src.blik-recurring-payments-introduction", "section": "implementation models; supporting banks management", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "blik:src.blik-recurring-payments-model-a", "section": "how it works; frequency; invitation data", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK Recurring Payments introduction and model A 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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "BLIK Recurring Payments pages (undated) as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.blik-recurring-payments-introduction", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the three models: A (fixed amount and frequency, no confirmation, fixed expiry), M (confirmation every time, variable amount and frequency), and O (no confirmation, variable amount and frequency, dated or indefinite), and that not every bank supports recurring payments." }, { "source": "blik:src.blik-recurring-payments-model-a", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms model A's expiration date may be set up to 10 years ahead, and that automatic authorisation without confirmation is possible for only one recurring transaction per frequency period, with a second transaction or a different amount in the same period requiring the user's confirmation in the app." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:mandate.recurring-payment", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "blik:state.recurring-payment-active", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "blik:state.recurring-payment-expired", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "blik:rule.recurring-retry-72-hours", "id": "rule.recurring-retry-72-hours", "rail": "blik", "class": "Rule", "name": "Recurring transaction short of funds: 72 hours of bank retries", "statement": "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.", "rests_on": "guidance", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "blik:src.blik-recurring-payments-introduction", "section": "unsuccessful recurring transactions; NODELAY flag", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "blik:src.blik-faq", "section": "no money on the account when a recurring payment is due", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "blik:exc.decline", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK Recurring Payments introduction page and 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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "BLIK Recurring Payments introduction page and BLIK FAQ as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.blik-recurring-payments-introduction", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the 72 hour bank retry window on insufficient funds or exceeded limits, the NODELAY flag skipping that period for models A and O with the transaction marked unsuccessful immediately, and PSP's recommended 24 hour interval between manual merchant retries." }, { "source": "blik:src.blik-faq", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms PSP's FAQ statement that a recurring payment not made for lack of funds may be retried by the bank, shop or service." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:exc.decline", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "blik:mandate.recurring-payment", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "blik:rule.refund-to-user", "id": "rule.refund-to-user", "rail": "blik", "class": "Rule", "name": "Merchant refunds are new credit transactions", "statement": "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.", "rests_on": "rule", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§2 (definition of Transakcja Mobilna c); §12.2; §29.13", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "blik:src.stripe-blik", "section": "refunds", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "blik:src.adyen-blik", "section": "feature table", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "blik:src.blik-faq", "section": "returning goods paid with contactless BLIK", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.acquirer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.refund-to-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition approved 15 April 2026, read in Polish 2026-09-19 and stated in Orca's own words and order, §2, §12.2 and §29.13; Stripe, Adyen and BLIK FAQ 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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the refund to the user as its own transaction type crediting the user through the merchant's acquirer or Mastercard, started in the app or with the original transaction's identifier, with the acquirer owing the issuer the refunded amount through BLIK clearing." }, { "source": "blik:src.stripe-blik", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms Stripe's statement that BLIK supports full and partial refunds, posted by the bank immediately or within a couple of hours." }, { "source": "blik:src.adyen-blik", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms Adyen's feature table marks refunds, partial refunds and multiple partial refunds all with a checkmark for BLIK, read directly from the page's emoji markup." }, { "source": "blik:src.blik-faq", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms PSP's FAQ statement that returning goods paid with contactless BLIK is usually done by tapping the same phone on the terminal." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:rule.rulebook-changes", "id": "rule.rulebook-changes", "rail": "blik", "class": "Rule", "name": "PSP changes the rulebook and fees on its own", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§27.1 to §27.3; §27.6; §27.7; §32.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition approved 15 April 2026, read in Polish 2026-09-19 and stated in Orca's own words and order, §27.1 to §27.3, §27.6, §27.7 and §32.1.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms PSP may amend the rulebook unilaterally with a two month adjustment period, that a change granting a participant rights without affecting others may bind earlier through an annex, that PSP sets fees on its own on objective criteria, and that the rulebook prevails over the participation agreement in a conflict." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:rule.security-deposits", "id": "rule.security-deposits", "rail": "blik", "class": "Rule", "name": "Security deposits: cash-deposit acquirers and Kasa Krajowa", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§7¹; §7²", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.acquirer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.cash", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.code-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition approved 15 April 2026, read in Polish 2026-09-19 and stated in Orca's own words and order, §7¹ and §7².", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the acquirer cash-deposit security deposit formula (twice average daily volume, minimum 400,000 PLN, computed by the fifth and notified by the seventh of each month, with top-up deadlines) and the Kasa Krajowa deposit formula (five times average daily transaction value, minimum 100,000 PLN before the first full month, paid within three business days of connection)." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:rule.sessions-multi-session-edition", "id": "rule.sessions-multi-session-edition", "rail": "blik", "class": "Rule", "name": "Clearing and settlement sessions, multi-session model", "statement": "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.", "rests_on": "rule", "facet": "settlement", "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [ "blik:txn.code-payment", "blik:txn.cash", "blik:txn.refund-to-user", "blik:txn.blik-c", "blik:txn.recurring" ], "excludes": [], "text": "participants in the multi-session settlement model only" }, "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-multi-session-2026-04-15", "section": "§2 (definition of Sesja Rozrachunkowa PSP); §29.6; §29.7; §29.9 to §29.12", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.acquirer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.code-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.cash", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.refund-to-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.blik-c", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, multi-session edition approved 15 April 2026, read in Polish 2026-09-19, §2, §29.6, §29.7 and §29.9 to §29.12. The timetable itself is in Annex 4b, not published.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, multi-session edition approved 15 April 2026, read 2026-09-19 (this provision differs in the single-session edition)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-multi-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms that in the multi-session edition several clearing sessions group into settlement sessions with the timetable set in a non-public operating procedure, and that public-holiday transactions go into the settlement session processed the next business day, differing from the single-session edition's text at the same section numbers." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:rule.sessions-single-session-edition", "id": "rule.sessions-single-session-edition", "rail": "blik", "class": "Rule", "name": "Clearing sessions, single-session model", "statement": "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.", "rests_on": "rule", "facet": "settlement", "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [ "blik:txn.code-payment", "blik:txn.cash", "blik:txn.refund-to-user", "blik:txn.blik-c", "blik:txn.recurring" ], "excludes": [], "text": "participants in the single-session settlement model only" }, "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§29.5 to §29.7; §29.9 to §29.13", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.acquirer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.code-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.cash", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.refund-to-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.blik-c", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition approved 15 April 2026, read in Polish 2026-09-19 and stated in Orca's own words and order, §29.5 to §29.13.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026, read 2026-09-19 (this provision differs in the multi-session edition)", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms that each clearing session in the single-session model ends at midnight, that public-holiday transactions go into the next business day's session, that PSP publishes reconciliation files promptly with a participant duty to check and report discrepancies, and that BLIK-C refunds join a session only when Mastercard reports them." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:rule.settlement-entity", "id": "rule.settlement-entity", "rail": "blik", "class": "Rule", "name": "Every participant settles through a settlement entity", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§4.1 f to h; §4.3; §31.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.settlement-entity", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.acquirer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.code-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.cash", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.refund-to-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.blik-c", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition approved 15 April 2026, read in Polish 2026-09-19 and stated in Orca's own words and order, §4.1 f to h, §4.3 and §31.2.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms that a participant is itself a settlement entity or names one, that a settlement entity must credit the participant it settles for after the run, and that an indirect participant settles through a direct issuer's account." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:rule.settlement-guarantee", "id": "rule.settlement-guarantee", "rail": "blik", "class": "Rule", "name": "Settlement guarantee among issuers", "statement": "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.", "rests_on": "rule", "facet": "settlement", "parameters": { "liability_holder": { "role": "blik:role.issuer", "condition": "when any issuer cannot fund its net position in the main or first reserve run", "text": "the surviving issuers jointly fund the defaulting issuer's position, and the defaulter repays them with statutory interest" } }, "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§3.10; §7.2 e, f; §31.11 to §31.16", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.code-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.cash", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.refund-to-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.blik-c", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition approved 15 April 2026, read in Polish 2026-09-19 and stated in Orca's own words and order, §3.10, §7.2 e and f, and §31.11 to §31.16. The formula is in Annex 4a, not published.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the withdraw-and-reserve-run mechanism when an issuer lacks funds, PSP blocking the short issuer and its dependents and telling NBP, the surviving issuers' obligation raised by a non-public formula, the bilateral fallback if the reserve run also fails, and the defaulting issuer's duty to repay with statutory interest." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:rule.settlement-order-irrevocable", "id": "rule.settlement-order-irrevocable", "rail": "blik", "class": "Rule", "name": "The settlement order is entered and fixed at positive authorisation", "statement": "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.", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§29.2 to §29.4; §31.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.code-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.cash", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.refund-to-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.blik-c", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition approved 15 April 2026, read in Polish 2026-09-19 and stated in Orca's own words and order, §29.2 to §29.4 and §31.3. That the Act's settlement order status gives insolvency protection is [Inference] from the Act's purpose; the Act itself was not read.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms that the settlement order enters the BLIK system the moment PSP registers the issuer's positive authorisation, that it cannot be revoked from then on, that an indirect participant's order counts as entered by the direct participant settling for it, and that PSP's SORBNET3 orders have the effect of settlement orders under the Settlement Finality Act; the Act itself was not read." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:rule.sorbnet3-settlement-run", "id": "rule.sorbnet3-settlement-run", "rail": "blik", "class": "Rule", "name": "Settlement in SORBNET3 through PSP's auxiliary account", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§2 (definition of Rachunek Pomocniczy PSP, Rozrachunek); §7.2 a, g; §31.1; §31.4 to §31.10", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.settlement-entity", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.code-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.cash", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.refund-to-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.blik-c", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "blik:role.nbp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition approved 15 April 2026, read in Polish 2026-09-19 and stated in Orca's own words and order, §2, §7.2 a and g, and §31.1 and §31.4 to §31.10. The single-session §31.9 also mentions a technical account the definitions never define; the multi-session edition drops that sentence, and nothing here rests on it.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms settlement in SORBNET3 through PSP's auxiliary account under settlement procedure A, one net debit order per issuer with credits to acquirers and Mastercard, one run within one business day except when the guarantee forces bilateral settlement, Monday to Friday except Polish public holidays, and the auxiliary account returning to zero before and after." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:rule.suspension-and-exclusion", "id": "rule.suspension-and-exclusion", "rail": "blik", "class": "Rule", "name": "Suspension and exclusion of a participant", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§17 to §19", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "blik:role.nbp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition approved 15 April 2026, read in Polish 2026-09-19 and stated in Orca's own words and order, §17 to §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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the suspension and exclusion triggers (supervisory suspension, settlement guarantee triggered by a shortfall, persistent breach), the one-month cure period, the NBP account closure route with its own timeline, the written-warning process for other breaches, notice to all participants and NBP, and that issuer and acquirer status suspend or exclude independently." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:rule.temporary-block", "id": "rule.temporary-block", "rail": "blik", "class": "Rule", "name": "PSP may block a participant temporarily", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§21", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.code-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.cash", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.refund-to-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.blik-c", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.p2p", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.p2p-request", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition approved 15 April 2026, read in Polish 2026-09-19 and stated in Orca's own words and order, §21.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the three grounds for a temporary block (conduct breaches, non-conforming or unexpected messages, and the 15 minute no-response or 50 percent decline thresholds not caused by the user or PSP), and that the block lifts once the participant e-mails PSP that the cause is removed." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:rule.unauthorised-transaction-reporting", "id": "rule.unauthorised-transaction-reporting", "rail": "blik", "class": "Rule", "name": "Issuers report unauthorised transactions within two business days", "statement": "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.", "rests_on": "rule", "facet": "liability", "parameters": { "time_window": { "count": 2, "unit": "business_day", "from": "discovery", "text": "within 2 business days of identifying the case" } }, "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§7.2 o, p; §24.4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.code-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.cash", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.refund-to-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.blik-c", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.p2p", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.p2p-request", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition approved 15 April 2026, read in Polish 2026-09-19 and stated in Orca's own words and order, §7.2 o and p, and §24.4.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the issuer's duty to monitor unauthorised transactions and report each identified case to PSP within two business days, its duty to warn users about online and app payment risks, and PSP's own duty to report unauthorised transactions to NBP and other authorities as the law requires." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:rule.user-approval-window", "id": "rule.user-approval-window", "rail": "blik", "class": "Rule", "name": "Time the user has to approve in the app: processors disagree", "statement": "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.", "rests_on": "practice", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "blik:src.stripe-blik", "section": "overview", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "blik:src.adyen-blik", "section": "shopper flow, BLIK with code", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.code-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Stripe and Adyen BLIK pages, read 2026-09-19. Neither is the operator's text; the conflict is unresolved [Unverified].", "confidence": "low" }, "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Stripe and Adyen BLIK pages as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.stripe-blik", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms Stripe states customers have 60 seconds to authorize a BLIK payment after it starts, timing out after that." }, { "source": "blik:src.adyen-blik", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms Adyen states the shopper must authorize the payment within 45 seconds, differing from Stripe's 60 second figure; neither is a PSP rule." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:rule.user-complains-to-own-bank", "id": "rule.user-complains-to-own-bank", "rail": "blik", "class": "Rule", "name": "Users complain to their own bank", "statement": "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.", "rests_on": "guidance", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "blik:src.blik-faq", "section": "where to complain", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "blik:role.issuer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.code-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.cash", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.refund-to-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.blik-c", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.p2p", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.p2p-request", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "blik:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "blik:exc.complaint", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK FAQ, read 2026-09-19; the rulebook's complaint route (§9) runs between participants and PSP.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "BLIK FAQ as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.blik-faq", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the FAQ tells users to complain to the bank whose app they used for a standard transaction, and separately gives the same answer for contactless and recurring payment complaints." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:src.adyen-blik", "id": "src.adyen-blik", "rail": "blik", "class": "RuleSource", "name": "Adyen Docs: BLIK", "summary": "Adyen's documentation for BLIK: code life and approval window, BLIK OneClick, and a feature table (refunds and partial refunds supported; recurring and chargebacks not supported through Adyen). A processor's description, secondary.", "publisher": "Adyen", "url": "https://docs.adyen.com/payment-methods/blik", "source_class": "secondary", "kind": "web_page", "edition": "live page as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The page itself, fetched and read on 2026-09-19; the feature table's marks were read from the page markup.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-19 for the BLIK rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "live page as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "blik:rule.authorisation-flows", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.one-time-code-validity", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.processor-claims-process", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.refund-to-user", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.user-approval-window", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "blik:src.blik-change-history", "id": "src.blik-change-history", "rail": "blik", "class": "RuleSource", "name": "BLIK change history (blik.com/historia-zmian)", "summary": "PSP's public timeline of BLIK features and corporate events from 2019 to 2024, including the start of contactless BLIK with Mastercard, phone transfer requests, NBP's classification of BLIK as a significant retail payment system, and the Romanian and Slovak companies. It lists features, not rule changes.", "publisher": "Polski Standard Płatności S.A.", "url": "https://www.blik.com/historia-zmian", "source_class": "public_primary", "kind": "web_page", "edition": "live page as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The page itself, fetched and read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-19 for the BLIK rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "live page as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "blik:role.nbp", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "blik:src.blik-faq", "id": "src.blik-faq", "rail": "blik", "class": "RuleSource", "name": "BLIK FAQ (blik.com/faq)", "summary": "PSP's public questions and answers for BLIK users, in Polish: which banks offer BLIK, how long a code lives, when a PIN is needed, where to complain, contactless BLIK on Mastercard terminals, and recurring payments. Consumer guidance, not rule text.", "publisher": "Polski Standard Płatności S.A.", "url": "https://www.blik.com/faq", "source_class": "public_primary", "kind": "web_page", "edition": "live page as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The page itself, fetched and read in full on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-19 for the BLIK rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "live page as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "blik:rule.blik-c-acceptance", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.issuer-set-limits", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.one-time-code-validity", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.pin-above-50-pln", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.recurring-cancel-in-banking-app", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.recurring-retry-72-hours", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.refund-to-user", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.user-complains-to-own-bank", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:state.recurring-payment-active", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:state.recurring-payment-deleted-by-user", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "blik:txn.blik-c", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "blik:txn.cash", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "blik:txn.code-payment", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "blik:src.blik-recurring-payments-introduction", "id": "src.blik-recurring-payments-introduction", "rail": "blik", "class": "RuleSource", "name": "BLIK Recurring Payments: Introduction", "summary": "PSP's English integration pages for BLIK recurring payments, introduction: the recurring payment as the user's consent confirmed in the banking app, the recurring transaction as a separate merchant-started event, the three models (A, M, O), the refuseNoPayId and NODELAY flags, the ER_PAYID_UNHANDLED rejection, and the 72 hour retry by the bank.", "publisher": "Polski Standard Płatności S.A.", "url": "https://www.blik.com/lp/reccuring-payments/Introduction.141951041.html", "source_class": "authoritative_primary", "kind": "integration_guide", "edition": "undated live page as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [ { "type": "see_also", "to": "blik:src.blik-recurring-payments-model-a", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The page itself, fetched and read in full on 2026-09-19. Classed as authoritative for the recurring interface because the operator writes it; it is integration guidance rather than rulebook text.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-19 for the BLIK rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "undated live page as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "blik:rule.recurring-cancel-in-banking-app", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.recurring-consent-in-banking-app", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.recurring-flags", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.recurring-models", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.recurring-retry-72-hours", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:src.blik-recurring-payments-model-a", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "blik:state.recurring-payment-active", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:state.recurring-payment-deleted-by-user", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "blik:state.recurring-payment-expired", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "blik:txn.recurring", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "blik:src.blik-recurring-payments-model-a", "id": "src.blik-recurring-payments-model-a", "rail": "blik", "class": "RuleSource", "name": "BLIK Recurring Payments: Model A", "summary": "PSP's English integration page for model A of BLIK recurring payments: fixed amount, fixed frequency and a set expiry of up to 10 years, automatic authorisation of one recurring transaction per period, and what the merchant must show and send.", "publisher": "Polski Standard Płatności S.A.", "url": "https://www.blik.com/lp/reccuring-payments/Model-A.141951045.html", "source_class": "authoritative_primary", "kind": "integration_guide", "edition": "undated live page as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [ { "type": "see_also", "to": "blik:src.blik-recurring-payments-introduction", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The page itself, fetched and read in full on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-19 for the BLIK rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "undated live page as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "blik:rule.recurring-consent-in-banking-app", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.recurring-models", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:src.blik-recurring-payments-introduction", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "blik:state.recurring-payment-active", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:state.recurring-payment-expired", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "blik:src.kir-express-elixir-bank-page", "id": "src.kir-express-elixir-bank-page", "rail": "blik", "class": "RuleSource", "name": "Express Elixir, KIR page for banks", "summary": "KIR's public page on Express Elixir for banks: round the clock operation including holidays, the transaction limits of 100,000 PLN and 250,000 PLN for payments to tax and customs authorities, and the link to the current rulebook.", "publisher": "Krajowa Izba Rozliczeniowa S.A.", "url": "https://www.kir.pl/nasza-oferta/banki/rozliczenia/express-elixir", "source_class": "public_primary", "kind": "web_page", "edition": "live page as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The page itself, fetched and read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-19 for the BLIK rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "live page as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "blik:rule.express-elixir-p2p-limit", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "blik:src.kir-express-elixir-rulebook-1-91", "id": "src.kir-express-elixir-rulebook-1-91", "rail": "blik", "class": "RuleSource", "name": "Regulamin systemu Express Elixir, wersja 1.91", "summary": "KIR's rulebook for Express Elixir, the Polish instant credit transfer system that carries most BLIK phone transfers under the MP2P order code. Cited only for the P2P leg: the MP2P code, the system transaction limit and when an order becomes irrevocable. Orca holds no Express Elixir rail.", "publisher": "Krajowa Izba Rozliczeniowa S.A.", "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", "kind": "rulebook", "edition": "version 1.91, in force from 1 February 2026; PDF of 32 pages, SHA-256 2fe15564c7ada4df5ad6324bfb5221ef4cd4ccdd2336c538131a029695911f2b", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, fetched on 2026-09-19; definitions 14, 15, 36 and 37, §18 and the version history read.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-19 for the BLIK rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "version 1.91, in force from 1 February 2026; PDF of 32 pages, SHA-256 2fe15564c7ada4df5ad6324bfb5221ef4cd4ccdd2336c538131a029695911f2b", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "blik:rule.express-elixir-p2p-limit", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.p2p-alias-lookup", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.p2p-express-elixir-irrevocable", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:txn.p2p", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "blik:src.psp-blik-rulebook-multi-session-2026-04-15", "id": "src.psp-blik-rulebook-multi-session-2026-04-15", "rail": "blik", "class": "RuleSource", "name": "Regulamin Systemu Płatności Mobilnych BLIK, multi-session edition approved 15 April 2026", "summary": "The same rulebook in the edition that binds participants in the multi-session settlement model. A text comparison on 2026-09-19 found it differs from the single-session edition only where settlement sessions are concerned: it defines a settlement session as a group of clearing sessions settled together, moves the session timetable into a non-public operating procedure, drops the words tying clearing and settlement files to business days in §16.2, §29.5 and §29.9, and drops one sentence of §31.9.", "publisher": "Polski Standard Płatności S.A.", "url": "https://www.blik.com/download/pobierz/regulamin-1", "source_class": "authoritative_primary", "kind": "rulebook", "edition": "approved by the PSP Management Board on 15 April 2026, multi-session model; PDF of 56 pages, 1,467,481 bytes, SHA-256 c0cf1775f7db393f0df1a713cf9bff8df393426ed5cef8a4f6f5e7c214a990ae", "access": "open", "consulted_on": "2026-09-19", "relations": [ { "type": "see_also", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The document itself, downloaded from the BLIK documentation page and read on 2026-09-19; compared with the single-session edition sentence by sentence.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-19 for the BLIK rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "approved by the PSP Management Board on 15 April 2026, multi-session model; PDF of 56 pages, 1,467,481 bytes, SHA-256 c0cf1775f7db393f0df1a713cf9bff8df393426ed5cef8a4f6f5e7c214a990ae", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "blik:rail.blik", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.net-clearing", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.sessions-multi-session-edition", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "id": "src.psp-blik-rulebook-single-session-2026-04-15", "rail": "blik", "class": "RuleSource", "name": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved 15 April 2026", "summary": "PSP's public rulebook for BLIK, in Polish: Part A governs the BLIK payment scheme and Part B the BLIK payment system. This edition binds participants in the single-session settlement model. Its annexes (price lists, fees, the Technical Specification for Participants, the operating procedures, the functionality table and the data card) are listed but not published with it.", "publisher": "Polski Standard Płatności S.A.", "url": "https://www.blik.com/download/pobierz/regulamin", "source_class": "authoritative_primary", "kind": "rulebook", "edition": "approved by the PSP Management Board on 15 April 2026, single-session model; PDF of 56 pages, 1,467,405 bytes, SHA-256 b78d88aadc111c33442ce3504e245a332d2f1b3f2a69b30ab6deb46b05a6be57", "access": "open", "consulted_on": "2026-09-19", "relations": [ { "type": "see_also", "to": "blik:src.psp-blik-rulebook-multi-session-2026-04-15", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The document itself, downloaded from the BLIK documentation page and read in full on 2026-09-19 (text extracted with pypdf).", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-19 for the BLIK rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "approved by the PSP Management Board on 15 April 2026, single-session model; PDF of 56 pages, 1,467,405 bytes, SHA-256 b78d88aadc111c33442ce3504e245a332d2f1b3f2a69b30ab6deb46b05a6be57", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "blik:rail.blik", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "blik:exc.cancellation-correction", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:exc.complaint", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:exc.decline", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:role.acquirer", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:role.institutional-user", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:role.issuer", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:role.mastercard-cooperating-scheme", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:role.merchant", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:role.nbp", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:role.psp", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:role.settlement-entity", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:role.user", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.authorisation-flows", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.bad-faith-and-crime-liability", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.blik-c-acceptance", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.blik-c-mastercard-position", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.cancellation-or-correction-13-months", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.complaint-alert-threshold", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.complaint-fault-pays", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.complaint-ticket-process", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.continuous-operation", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.declined-authorisation-never-settles", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.disputes-over-goods-outside-scheme", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.downtime-notice", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.issuer-decides-authorisation", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.issuer-is-users-payment-service-provider", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.message-standards-technical-specification", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.net-clearing", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.one-time-code-validity", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.order-entry-and-irrevocable-authorisation", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.p2p-alias-lookup", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.p2p-express-elixir-irrevocable", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.p2p-request-requester-credited-on-acceptance", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.participant-duties", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.participation-eligibility", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.per-transaction-limit-unpublished", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.psp-fraud-and-gambling-rejection", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.psp-operator-duties", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.recurring-consent-in-banking-app", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.refund-to-user", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.rulebook-changes", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.security-deposits", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.sessions-single-session-edition", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.settlement-entity", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.settlement-guarantee", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.settlement-order-irrevocable", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.sorbnet3-settlement-run", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.suspension-and-exclusion", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.temporary-block", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.unauthorised-transaction-reporting", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:src.psp-blik-rulebook-multi-session-2026-04-15", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "blik:txn.blik-c", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:txn.cash", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:txn.code-payment", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:txn.p2p-request", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:txn.p2p", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:txn.recurring", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "blik:txn.refund-to-user", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "blik:src.stripe-blik", "id": "src.stripe-blik", "rail": "blik", "class": "RuleSource", "name": "Stripe Docs: BLIK payments", "summary": "Stripe's documentation for accepting BLIK: code life and approval window, refunds, and how Stripe presents BLIK's claims process to its merchants. A processor's description, secondary.", "publisher": "Stripe", "url": "https://docs.stripe.com/payments/blik", "source_class": "secondary", "kind": "web_page", "edition": "live page as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The page itself, fetched and read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-19 for the BLIK rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "live page as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "blik:rule.one-time-code-validity", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.processor-claims-process", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.refund-to-user", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "blik:rule.user-approval-window", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "blik:state.recurring-payment-active", "id": "state.recurring-payment-active", "rail": "blik", "class": "LifecycleState", "name": "BLIK recurring payment: active", "summary": "The user has confirmed the merchant's invitation in their banking app, so the bank now keeps the recurring payment on its list and the merchant may start recurring transactions under it: charged automatically in models A and O, or put to the user for confirmation each time in model M. It lasts until its expiry date (required in model A, at most 10 years ahead) or, in models M and O, until cancelled if no date was set. It exists only at the bank where it was confirmed; moving bank means setting it up again.", "terminal": false, "money_moved": "no", "visible_as": null, "relations": [ { "type": "precedes", "to": "blik:state.recurring-payment-deleted-by-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "precedes", "to": "blik:state.recurring-payment-expired", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "blik:rule.recurring-consent-in-banking-app", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "blik:rule.recurring-models", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "blik:rule.recurring-cancel-in-banking-app", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "blik:src.blik-recurring-payments-introduction", "section": "Recurring Payment; implementation models table (expiration row)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "blik:src.blik-recurring-payments-model-a", "section": "how it works; invitation data (alias expiration date)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "blik:src.blik-faq", "section": "recurring payment questions (starting, details of stored recurring payments, changing bank)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "PSP's BLIK Recurring Payments Introduction and Model A pages (English) and the BLIK FAQ recurring payment answers (Polish), all read 2026-09-23 on blik.com. The pages describe a recurring payment that exists once the user confirms it in the banking app and that runs to an expiry date or indefinitely; they give no status value for it, so visible_as is null. The Polish FAQ is summarised in Orca's own words, not translated.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the pages read are undated", "effective_to": null, "effective_note": "Drafted 2026-09-23 by the product view slice 3 drafting session from the documents named in basis, each opened and read that day. PSP's change history dates a new form of BLIK recurring payments to December 2024 at one bank, as recorded on the Mandate; when the current models first applied is [Unverified].", "source_edition": "BLIK Recurring Payments Introduction and Model A pages (undated) and BLIK FAQ, as read 2026-09-23", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.blik-recurring-payments-introduction", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms a recurring payment is the user consent confirmed in the banking app after the user starts it at the merchant, that the user can see and cancel all recurring payments in the app, that a recurring transaction is a separate merchant initiated event, that models A and O charge automatically and model M needs confirmation each time, and that model A requires a fixed expiration date while models M and O may be indefinite or dated. Does not name a status value for the record" }, { "source": "blik:src.blik-recurring-payments-model-a", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms model A requires the recurring payment's expiration date to be specified and allows up to 10 years, and that recurring transactions run automatically without user confirmation except the first payment" }, { "source": "blik:src.blik-faq", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms that a recurring payment enabled at one bank must be recreated from scratch at a different bank rather than carried over, and that its detail view in the app shows whether future payments run automatically or need confirmation each time" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "blik:state.recurring-payment-deleted-by-user", "id": "state.recurring-payment-deleted-by-user", "rail": "blik", "class": "LifecycleState", "name": "BLIK recurring payment: deleted by the user", "summary": "The user has removed the recurring payment from the list in their banking app, which is how BLIK lets a user give it up. The merchant can no longer charge through it. Removing it ends the BLIK consent only: whether the user's contract with the merchant ends too is for the merchant's own terms.", "terminal": true, "money_moved": "no", "visible_as": null, "relations": [ { "type": "governed_by", "to": "blik:rule.recurring-cancel-in-banking-app", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "blik:src.blik-recurring-payments-introduction", "section": "Recurring Payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "blik:src.blik-faq", "section": "recurring payment questions (giving up a recurring payment)", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "PSP's BLIK Recurring Payments Introduction page (the user can see and cancel every recurring payment in the banking app) and the BLIK FAQ answer on giving up a recurring payment by deleting it in the app, which adds that this need not end the service with the merchant. Both read 2026-09-23. No status value is given, so visible_as is null. That the merchant can no longer charge through a deleted recurring payment is [Inference] from what deleting the consent means; the pages do not say what a later transaction against it returns. Whether a merchant or a bank can also end one is not said in any source read.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the pages read are undated", "effective_to": null, "effective_note": "Drafted 2026-09-23 by the product view slice 3 drafting session from the documents named in basis, each opened and read that day.", "source_edition": "BLIK Recurring Payments Introduction page (undated) and BLIK FAQ, as read 2026-09-23", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "blik:state.recurring-payment-active", "type": "precedes", "status": "draft", "effective_status": "draft" } ] }, { "uid": "blik:state.recurring-payment-expired", "id": "state.recurring-payment-expired", "rail": "blik", "class": "LifecycleState", "name": "BLIK recurring payment: past its expiry date", "summary": "The recurring payment has reached the expiry date set when it was created. In model A that date is compulsory and at most 10 years out, and automatic charges run only until it; in models M and O a date is optional, so a recurring payment without one never reaches this state. After it, the merchant needs a new recurring payment confirmed by the user.", "terminal": true, "money_moved": "no", "visible_as": null, "relations": [ { "type": "governed_by", "to": "blik:rule.recurring-models", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "blik:src.blik-recurring-payments-introduction", "section": "implementation models table (expiration row)", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "blik:src.blik-recurring-payments-model-a", "section": "how it works; invitation data (alias expiration date)", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "PSP's BLIK Recurring Payments Introduction page, whose model table gives the expiry for each model, and the Model A page, which requires an expiry date of up to 10 years on the invitation; both read 2026-09-23. No status value is given, so visible_as is null. That an expired recurring payment is terminal and a new one must be confirmed is [Inference]: the pages say charges run until the date and do not describe renewal.", "confidence": "low" }, "currency": { "effective_since": "Unknown: the pages read are undated", "effective_to": null, "effective_note": "Drafted 2026-09-23 by the product view slice 3 drafting session from the documents named in basis, each opened and read that day.", "source_edition": "BLIK Recurring Payments Introduction and Model A pages (undated), as read 2026-09-23", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "blik:state.recurring-payment-active", "type": "precedes", "status": "draft", "effective_status": "draft" } ] }, { "uid": "blik:txn.blik-c", "id": "txn.blik-c", "rail": "blik", "class": "TransactionType", "name": "Contactless BLIK (BLIK-C)", "summary": "A contactless payment from the mobile app at a POS terminal in the BLIK-C acceptance network (terminals marked BLIK or Mastercard, in Poland or abroad), using a Mastercard token tied to the user's alias. It is routed through Mastercard as the Cooperating Scheme, authorised by the issuer and settled with Mastercard's position in the BLIK system. The terminal slip may read MASTERCARD CONTACTLESS. PSP's FAQ says it works on Android (and HarmonyOS in some banks), without a payment card.", "sec_code": null, "directions": [ "debit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§2 (definitions of Transakcja BLIK-C, Transakcja Mobilna d, Sieć Akceptacji Transakcji BLIK-C); §11.6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "blik:src.blik-faq", "section": "contactless BLIK questions", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:participants", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition, §2 and §11.6; BLIK FAQ; read 2026-09-19. sec_code is null: BLIK has no entry class codes.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms contactless BLIK as a mobile transaction at a BLIK-C acceptance network terminal, using a Mastercard token tied to the alias, routed through Mastercard as the Cooperating Scheme; the FAQ confirms the terminal slip may read MASTERCARD CONTACTLESS and that no payment card is needed." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:rule.authorisation-flows", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.bad-faith-and-crime-liability", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.blik-c-acceptance", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.blik-c-mastercard-position", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.cancellation-or-correction-13-months", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.complaint-alert-threshold", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.complaint-fault-pays", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.complaint-ticket-process", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.continuous-operation", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.declined-authorisation-never-settles", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.disputes-over-goods-outside-scheme", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.issuer-decides-authorisation", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.issuer-is-users-payment-service-provider", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.issuer-set-limits", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.message-standards-technical-specification", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.net-clearing", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.order-entry-and-irrevocable-authorisation", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.participant-duties", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.per-transaction-limit-unpublished", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.psp-fraud-and-gambling-rejection", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.sessions-multi-session-edition", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.sessions-single-session-edition", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.settlement-entity", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.settlement-guarantee", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.settlement-order-irrevocable", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.sorbnet3-settlement-run", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.temporary-block", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.unauthorised-transaction-reporting", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.user-complains-to-own-bank", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "blik:txn.cash", "id": "txn.cash", "rail": "blik", "class": "TransactionType", "name": "Cash withdrawal or deposit", "summary": "Taking cash out of, or paying cash into, the user's account at an ATM or cash deposit machine on the user's instruction in the mobile app, authorised with a BLIK code and cleared in the BLIK system. PSP's FAQ names the ATM networks. Acquirers that take deposits outside their own network without a securing issuer post a security deposit.", "sec_code": null, "directions": [ "debit", "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§2 (definition of Transakcja Mobilna b); §7¹", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "blik:src.blik-faq", "section": "which ATMs take BLIK", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition, §2 and §7¹; BLIK FAQ; read 2026-09-19. sec_code is null: BLIK has no entry class codes.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms cash withdrawal or deposit as a mobile transaction on the user's instruction in the app, and the security deposit duty on acquirers taking deposits outside their own network without a securing issuer." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:rule.authorisation-flows", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.bad-faith-and-crime-liability", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.cancellation-or-correction-13-months", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.complaint-alert-threshold", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.complaint-fault-pays", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.complaint-ticket-process", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.continuous-operation", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.declined-authorisation-never-settles", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.disputes-over-goods-outside-scheme", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.issuer-decides-authorisation", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.issuer-is-users-payment-service-provider", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.issuer-set-limits", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.message-standards-technical-specification", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.net-clearing", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.one-time-code-validity", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.order-entry-and-irrevocable-authorisation", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.participant-duties", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.per-transaction-limit-unpublished", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.pin-above-50-pln", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.psp-fraud-and-gambling-rejection", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.security-deposits", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.sessions-multi-session-edition", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.sessions-single-session-edition", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.settlement-entity", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.settlement-guarantee", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.settlement-order-irrevocable", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.sorbnet3-settlement-run", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.temporary-block", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.unauthorised-transaction-reporting", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.user-complains-to-own-bank", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "blik:txn.code-payment", "id": "txn.code-payment", "rail": "blik", "class": "TransactionType", "name": "Code payment to a merchant", "summary": "A payment from the user's account to a merchant, online or at a terminal, authorised with a BLIK code: a six digit one-time code PSP generates in the user's app, a one-time code the issuer registers after the user takes it from the acceptance device, or a standing alias. The merchant's acquirer sends it to PSP, the issuer authorises it, and it clears and settles in the BLIK system. PSP's FAQ also describes BLIK cheques, nine digit codes for paying or withdrawing cash [Inference: they run as code transactions; the rulebook does not name them].", "sec_code": null, "directions": [ "debit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§2 (definitions of Transakcja Mobilna a, Kod Jednorazowy, Alias); §11.3 to §11.5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "blik:src.blik-faq", "section": "what BLIK allows; whether BLIK works the same in every bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition, §2 and §11.3 to §11.5; BLIK FAQ; read 2026-09-19. sec_code is null: BLIK has no entry class codes.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms a code payment as a mobile transaction authorised with a PSP-generated one-time code, an issuer-registered one-time code, or a standing alias, routed through the acquirer to PSP and the issuer for authorisation." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:rule.authorisation-flows", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.bad-faith-and-crime-liability", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.cancellation-or-correction-13-months", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.complaint-alert-threshold", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.complaint-fault-pays", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.complaint-ticket-process", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.continuous-operation", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.declined-authorisation-never-settles", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.disputes-over-goods-outside-scheme", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.issuer-decides-authorisation", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.issuer-is-users-payment-service-provider", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.issuer-set-limits", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.message-standards-technical-specification", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.net-clearing", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.one-time-code-validity", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.order-entry-and-irrevocable-authorisation", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.participant-duties", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.per-transaction-limit-unpublished", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.pin-above-50-pln", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.processor-claims-process", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.psp-fraud-and-gambling-rejection", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.security-deposits", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.sessions-multi-session-edition", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.sessions-single-session-edition", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.settlement-entity", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.settlement-guarantee", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.settlement-order-irrevocable", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.sorbnet3-settlement-run", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.temporary-block", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.unauthorised-transaction-reporting", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.user-approval-window", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.user-complains-to-own-bank", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "blik:txn.p2p-request", "id": "txn.p2p-request", "rail": "blik", "class": "TransactionType", "name": "Transfer request (P2P-R)", "summary": "The payee starts it: a user sends, through PSP, a request naming another user by alias, with an amount and optional title. If the payer accepts in the app, the payer's bank sends the transfer internally, through Express Elixir (MP2P) or through the BLIK system, and the requester's bank credits the requester as soon as PSP reports the acceptance.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§2 (definition of Transakcja P2P-R); §23.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition, §2 and §23.2, read 2026-09-19. sec_code is null: BLIK has no entry class codes.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the transfer request as started by the payee, routed through PSP with an amount and optional title, and that the requester's bank credits the requester as soon as PSP reports the payer's acceptance." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:rule.continuous-operation", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.express-elixir-p2p-limit", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.issuer-is-users-payment-service-provider", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.issuer-set-limits", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.message-standards-technical-specification", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.p2p-alias-lookup", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.p2p-express-elixir-irrevocable", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.p2p-request-requester-credited-on-acceptance", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.participant-duties", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.temporary-block", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.unauthorised-transaction-reporting", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.user-complains-to-own-bank", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "blik:txn.p2p", "id": "txn.p2p", "rail": "blik", "class": "TransactionType", "name": "Phone transfer (P2P)", "summary": "A transfer between two users, or from an institutional user to a user, addressed by an alias such as a mobile number or e-mail address that PSP resolves to the payee's account in its mobile account base. With no acquirer involved, the payer's bank books it internally when it holds both accounts, and otherwise sends it through an instant payment system (Express Elixir, order code MP2P) or through the BLIK system.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§2 (definition of Transakcja P2P); §3.13; §23.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "blik:src.kir-express-elixir-rulebook-1-91", "section": "definition 15 (MP2P)", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition, §2, §3.13 and §23.1; Express Elixir rulebook 1.91, definition 15; read 2026-09-19. sec_code is null: BLIK has no entry class codes.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the phone transfer as an alias-addressed transfer between two users, or an institutional user and a user, resolved through PSP's mobile account base and booked internally, through Express Elixir with code MP2P, or through the BLIK system." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:rule.continuous-operation", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.express-elixir-p2p-limit", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.issuer-is-users-payment-service-provider", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.issuer-set-limits", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.message-standards-technical-specification", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.p2p-alias-lookup", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.p2p-express-elixir-irrevocable", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.p2p-request-requester-credited-on-acceptance", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.participant-duties", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.temporary-block", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.unauthorised-transaction-reporting", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.user-complains-to-own-bank", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "blik:txn.recurring", "id": "txn.recurring", "rail": "blik", "class": "TransactionType", "name": "Recurring transaction", "summary": "A single transaction a merchant starts under a recurring payment the user set up earlier. It is a separate event from the consent itself, may be authorised automatically or only after the user confirms it in the app depending on the model, and is authorised by the issuer like any other BLIK transaction.", "sec_code": null, "directions": [ "debit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "blik:src.blik-recurring-payments-introduction", "section": "Recurring Payment and Recurring Transaction; implementation models", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§2 (definition of Akceptant a, second indent)", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "BLIK Recurring Payments introduction page and BLIK rulebook §2, read 2026-09-19. sec_code is null: BLIK has no entry class codes.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.blik-recurring-payments-introduction", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the recurring transaction as a single transaction the merchant starts under an earlier recurring payment consent, a separate event from the consent itself, authorised automatically or with user confirmation depending on the model." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:mandate.recurring-payment", "type": "authorises", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.authorisation-flows", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.bad-faith-and-crime-liability", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.cancellation-or-correction-13-months", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.complaint-alert-threshold", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.complaint-fault-pays", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.complaint-ticket-process", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.continuous-operation", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.declined-authorisation-never-settles", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.disputes-over-goods-outside-scheme", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.issuer-decides-authorisation", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.issuer-is-users-payment-service-provider", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.issuer-set-limits", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.message-standards-technical-specification", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.net-clearing", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.one-time-code-validity", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.order-entry-and-irrevocable-authorisation", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.participant-duties", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.per-transaction-limit-unpublished", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.psp-fraud-and-gambling-rejection", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.recurring-cancel-in-banking-app", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.recurring-consent-in-banking-app", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.recurring-flags", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.recurring-models", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.recurring-retry-72-hours", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.sessions-multi-session-edition", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.sessions-single-session-edition", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.settlement-entity", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.settlement-guarantee", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.settlement-order-irrevocable", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.sorbnet3-settlement-run", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.temporary-block", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.unauthorised-transaction-reporting", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.user-complains-to-own-bank", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "blik:txn.refund-to-user", "id": "txn.refund-to-user", "rail": "blik", "class": "TransactionType", "name": "Refund to the user", "summary": "A transfer to the user's account through Mastercard or through the acquirer of the merchant that accepted the refund instruction, started either in the mobile app or with the unique identifier of the transaction being refunded. It is a transaction type of its own, not a reversal of the original. The acquirer owes the issuer the amount; a BLIK-C refund enters BLIK clearing only after Mastercard reports it.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "section": "§2 (definition of Transakcja Mobilna c); §12.2; §29.13", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "BLIK rulebook, single-session edition, §2, §12.2 and §29.13, read 2026-09-19. sec_code is null: BLIK has no entry class codes.", "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 from the BLIK rulebook editions approved on 15 April 2026. The rulebook prints no effective date and PSP publishes no rule change notices that were found, so when this provision first applied is [Unverified].", "source_edition": "Regulamin Systemu Płatności Mobilnych BLIK, single-session edition approved by the PSP Management Board on 15 April 2026, read 2026-09-19; the multi-session edition of the same date was compared by text and matches for the sections cited unless the record says otherwise", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms the refund to the user as its own mobile transaction type crediting the user through the merchant's acquirer or Mastercard, started in the app or with the original transaction's identifier, and that a BLIK-C refund enters clearing only once Mastercard reports it." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:rule.authorisation-flows", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.bad-faith-and-crime-liability", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.blik-c-mastercard-position", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.cancellation-or-correction-13-months", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.complaint-alert-threshold", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.complaint-fault-pays", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.complaint-ticket-process", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.continuous-operation", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.declined-authorisation-never-settles", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.disputes-over-goods-outside-scheme", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.issuer-decides-authorisation", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.issuer-is-users-payment-service-provider", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.issuer-set-limits", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.message-standards-technical-specification", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.net-clearing", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.order-entry-and-irrevocable-authorisation", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.participant-duties", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.per-transaction-limit-unpublished", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.psp-fraud-and-gambling-rejection", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.refund-to-user", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.sessions-multi-session-edition", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.sessions-single-session-edition", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.settlement-entity", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.settlement-guarantee", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.settlement-order-irrevocable", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.sorbnet3-settlement-run", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.temporary-block", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.unauthorised-transaction-reporting", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "blik:rule.user-complains-to-own-bank", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "blik:rule.issuer-is-users-payment-service-provider", "blik:rule.user-complains-to-own-bank", "blik:rule.recurring-consent-in-banking-app", "blik:rule.recurring-cancel-in-banking-app" ], "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.", "relations": [ { "type": "see_also", "to": "mastercard:consumer-law", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "blik:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "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": "blik:src.blik-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": "blik:src.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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:liability", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "blik:rule.issuer-decides-authorisation", "blik:rule.psp-fraud-and-gambling-rejection", "blik:rule.complaint-fault-pays", "blik:rule.temporary-block", "blik:rule.suspension-and-exclusion", "blik:rule.recurring-retry-72-hours" ], "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.", "relations": [ { "type": "see_also", "to": "blik:limits", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "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": "blik:src.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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:limits", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "blik:rule.order-entry-and-irrevocable-authorisation", "blik:rule.settlement-order-irrevocable", "blik:rule.p2p-express-elixir-irrevocable", "blik:rule.cancellation-or-correction-13-months" ], "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.", "relations": [ { "type": "see_also", "to": "mastercard:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "blik:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "blik:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "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": "blik:src.kir-express-elixir-rulebook-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:recall", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "blik:settlement", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "blik:rule.continuous-operation", "blik:rule.downtime-notice", "blik:rule.one-time-code-validity", "blik:rule.user-approval-window" ], "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.", "relations": [ { "type": "see_also", "to": "blik:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "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": "blik:src.blik-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "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.", "rules": [ "blik:rule.bad-faith-and-crime-liability", "blik:rule.complaint-fault-pays", "blik:rule.disputes-over-goods-outside-scheme", "blik:rule.unauthorised-transaction-reporting", "blik:rule.complaint-alert-threshold", "blik:rule.settlement-guarantee", "blik:rule.security-deposits" ], "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.", "relations": [ { "type": "see_also", "to": "mastercard:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "blik:consumer-law", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "blik:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:consumer-law", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "blik:return", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "blik:rule.per-transaction-limit-unpublished", "blik:rule.issuer-set-limits", "blik:rule.pin-above-50-pln", "blik:rule.psp-fraud-and-gambling-rejection", "blik:rule.express-elixir-p2p-limit" ], "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.", "relations": [ { "type": "see_also", "to": "blik:decision-points", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "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": "blik:src.kir-express-elixir-rulebook-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:decision-points", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "blik:rule.authorisation-flows", "blik:rule.message-standards-technical-specification", "blik:rule.p2p-alias-lookup", "blik:rule.recurring-models", "blik:rule.recurring-flags" ], "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.", "relations": [ { "type": "see_also", "to": "mastercard:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "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": "blik:src.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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "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.", "rules": [ "blik:rule.participation-eligibility", "blik:rule.participant-duties", "blik:rule.psp-operator-duties", "blik:rule.rulebook-changes", "blik:rule.blik-c-acceptance" ], "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.", "relations": [ { "type": "see_also", "to": "mastercard:participants", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "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": "blik:src.blik-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "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.", "rules": [ "blik:rule.order-entry-and-irrevocable-authorisation", "blik:rule.cancellation-or-correction-13-months" ], "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.", "relations": [ { "type": "see_also", "to": "mastercard:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "blik:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:finality", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "blik:rule.refund-to-user", "blik:rule.disputes-over-goods-outside-scheme", "blik:rule.user-complains-to-own-bank" ], "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.", "relations": [ { "type": "see_also", "to": "mastercard:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "blik:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "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": "blik:src.blik-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:return", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "blik:rule.declined-authorisation-never-settles", "blik:rule.complaint-ticket-process", "blik:rule.processor-claims-process" ], "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.", "relations": [ { "type": "see_also", "to": "mastercard:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "blik:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "blik:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "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": "blik:src.stripe-blik", "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": "blik:src.adyen-blik", "checked_on": "2026-09-19", "checked_by": "blik-validator-2026-09-19", "notes": "Confirms Adyen's feature table marks chargebacks unsupported for BLIK." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:liability", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "blik:refund", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "blik:rule.net-clearing", "blik:rule.sorbnet3-settlement-run", "blik:rule.sessions-single-session-edition", "blik:rule.sessions-multi-session-edition", "blik:rule.settlement-guarantee", "blik:rule.settlement-entity", "blik:rule.blik-c-mastercard-position", "blik:rule.p2p-request-requester-credited-on-acceptance" ], "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.", "relations": [ { "type": "see_also", "to": "mastercard:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "blik:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "blik:src.psp-blik-rulebook-single-session-2026-04-15", "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": "blik:src.psp-blik-rulebook-multi-session-2026-04-15", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "blik:finality", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "blik:hours", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "boleto:rail.boleto", "id": "rail.boleto", "class": "Rail", "rail": "boleto", "name": "Boleto (Brazil payment slip arrangement)", "governing_authority": "Banco Central do Brasil (BCB)", "country": "BR", "currency": "BRL", "operators": [ "Núclea (CIP S.A.), for SILOC and the central boleto database", "Banco Central do Brasil, for the STR" ], "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" ], "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "arts. 1 to 5, 16 to 21 and 26", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "boleto:src.nuclea-pfmi-report-v4", "section": "section 4, a.2 and b.6", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "source_class": null, "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:exc.entry-rejection", "id": "exc.entry-rejection", "rail": "boleto", "class": "Exception", "name": "Title entry rejected by the issuing bank", "summary": "When a beneficiary sends a title for registration in a CNAB240 remittance file, the bank may answer with movement code 03 (entry rejected) and up to five occurrence reasons from list A of field C047. No payment exists yet, so no money moves; the beneficiary corrects the data and sends the title again.", "money_moves": false, "outcome": "The title is not registered and cannot be presented or paid until a corrected entry is accepted.", "relations": [ { "type": "initiated_by", "to": "boleto:role.issuing-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "boleto:role.issuing-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "boleto:rule.entry-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "boleto:src.febraban-cnab240-v11-0", "section": "3.2.1 events (p. 66); C044 (p. 177); C047 list A (pp. 179 to 181)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "CNAB240 v11.0 3.2.1, C044 and C047, read 2026-09-19. A bank-to-client file standard.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-11", "effective_to": null, "effective_note": "Drafted 2026-09-19 from CNAB240 version 11.0, which Febraban marks preliminary (5.2). The date is that edition's date; the fields and codes cited are older, and when each first appeared was not traced.", "source_edition": "Layout Padrão Febraban 240 posições, version 11.0 of 2026-09-11, marked preliminary; PDF of 260 pages, relevant sections read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.febraban-cnab240-v11-0", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms movement code 03 (entrada rejeitada) and the list A occurrence reasons on the return file, 3.2.1, C044 and C047." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "boleto:rule.entry-rejection", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "boleto:exc.interbank-devolucao", "id": "exc.interbank-devolucao", "rail": "boleto", "class": "Exception", "name": "Interbank devolução and acerto de diferença", "summary": "The destination institution sends money back to the receiving institution (devolução), or the two settle a difference in amount (acerto de diferença), for a boleto payment that should not stand, such as a boleto settled twice or a payment taken out of conformity. It runs between institutions through the system that settled the original. The payer cannot start it; the payer is repaid by the receiving institution afterwards. Unlike Pix's devolução, it is not a new payment by the recipient.", "money_moves": true, "outcome": "Funds move from the destination institution back to the receiving institution through STR or SILOC, as the original did, and under the 2021 convention the receiving institution then makes the money available to the payer within one business day. The reason codes are in the convention's operating manuals and SILOC's, which Orca does not hold.", "relations": [ { "type": "initiated_by", "to": "boleto:role.destination-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "initiated_by", "to": "boleto:role.receiving-institution", "note": "Under the 2021 convention annex VII the receiving institution may ask for a devolução of a boleto paid in its own network.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "boleto:role.destination-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "boleto:rule.devolucao-same-system", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "boleto:rule.devolucao-next-business-day", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "boleto:rule.str-transfers-by-noon", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "boleto:rule.devolucao-convention-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "boleto:rule.nonconforming-payment-reversal-attempt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 16 §3; art. 18", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "boleto:src.convencao-cobranca-2021", "section": "arts. 31 and 32; annexes VI and VII", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "pix:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 arts. 16 and 18; 2021 convention arts. 31 and 32 and annexes VI and VII; read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 from Res. BCB 443, consolidated version 3.0. The date is the day the resolution entered into force (art. 26). The lines from the 2021 convention carry its own doubt: The 2021 convention entered into force on 2021-02-10 (art. 36) and was made under Circular 3.598/2012, which Res. BCB 443 revoked; Res. 443 art. 20 §4 required changes to the convention to be submitted to the BCB, and whether a later edition replaces the 2021 text was not established [Unverified].", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19; Convenção entre instituições participantes do SFN sobre a emissão, apresentação, processamento e liquidação interbancária dos boletos de pagamento, FB-0061/2021, signed 2021-02-05, in force from 2021-02-10; PDF of 39 pages read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms devolucao and acerto de diferenca run from the destination institution to the receiving institution through the system that settled the original, art. 16 par. 3 and art. 18." }, { "source": "boleto:src.convencao-cobranca-2021", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms annex VI's automatable grounds, annex VII's receiving-institution request within five business days, and the one business day repayment to the payer, arts. 31 and 32 and annexes VI and VII." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "boleto:rule.devolucao-convention-grounds", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.devolucao-next-business-day", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.devolucao-same-system", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.nonconforming-payment-reversal-attempt", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.str-transfers-by-noon", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "boleto:exc.payer-claim", "id": "exc.payer-claim", "rail": "boleto", "class": "Exception", "name": "Payer claim (alegação do pagador)", "summary": "A payer who disputes a title tells the beneficiary's bank, on paper at a branch or electronically if the payer is that bank's client; the bank passes the claim to the beneficiary, who decides whether to accept it. It is not a chargeback: no rule read obliges anyone to reverse a paid boleto.", "money_moves": false, "outcome": "The beneficiary accepts or rejects the claim and instructs its bank; any money back is between beneficiary and payer. Which instructions follow an accepted claim (for example a rebate or a write-off) is not stated in the standard [Inference].", "relations": [ { "type": "initiated_by", "to": "boleto:role.payer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "boleto:role.beneficiary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "boleto:rule.payer-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "boleto:src.febraban-cnab240-v11-0", "section": "3.2.1, information flow (p. 65) and payer claim events (p. 67)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "CNAB240 v11.0 3.2.1, read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-11", "effective_to": null, "effective_note": "Drafted 2026-09-19 from CNAB240 version 11.0, which Febraban marks preliminary (5.2). The date is that edition's date; the fields and codes cited are older, and when each first appeared was not traced.", "source_edition": "Layout Padrão Febraban 240 posições, version 11.0 of 2026-09-11, marked preliminary; PDF of 260 pages, relevant sections read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.febraban-cnab240-v11-0", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the payer's claim (alegacao) passes from the receiving bank to the beneficiary's bank and then to the beneficiary for a decision, 3.2.1 information flow and events." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "boleto:rule.payer-claim", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "boleto:role.bcb", "id": "role.bcb", "rail": "boleto", "class": "Role", "name": "Banco Central do Brasil (BCB)", "summary": "Regulator of the boleto arrangement under Res. BCB 443, which calls the boleto a payment arrangement. It runs the STR, where large boletos settle gross and SILOC's net positions settle; it approves changes to the participants' convention and publishes the associations that vote on it; and it lists the assets eligible for dynamic boletos.", "kind": "authority", "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "arts. 1, 13, 16, I, 20 §3 and 21 §6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "boleto:src.bcb-instrucao-normativa-611", "section": "art. 1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "boleto:src.nuclea-pfmi-report-v4", "section": "principle 9, KC 1 (p. 18)", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443; IN BCB 611; Núclea PFMI report v4 principle 9; read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 from Res. BCB 443, consolidated version 3.0. The date is the day the resolution entered into force (art. 26).", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the BCB regulates the boleto arrangement, sets the VR-Boleto threshold, lists dynamic-boleto assets by instrucao normativa, approves convention changes, and publishes the associations and votes, arts. 1, 13, 16, 20 and 21." }, { "source": "boleto:src.bcb-instrucao-normativa-611", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms IN 611 lists the asset types eligible for dynamic boletos, art. 1." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "boleto:rule.convention-governance", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.siloc-settlement-default", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "boleto:role.beneficiary", "id": "role.beneficiary", "rail": "boleto", "class": "Role", "name": "Beneficiary (beneficiário)", "summary": "The party a boleto pays: the original creditor or holder of the billed right, the one offering a product, service, contract or membership, or, for a deposit boleto, the holder of the account being funded. Formerly called cedente. It contracts with its issuing institution, has its boletos registered, and decides on payer claims and on write-offs.", "kind": "party", "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 3, I", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "boleto:src.febraban-cnab240-v11-0", "section": "3.2.1, participating entities and information flow (pp. 64 to 65)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 art. 3, I; 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 from Res. BCB 443, consolidated version 3.0. The date is the day the resolution entered into force (art. 26).", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the definition of beneficiario as original creditor or rights holder, offeror, or account holder, art. 3, I." }, { "source": "boleto:src.febraban-cnab240-v11-0", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the beneficiario delivers titles to the bank for collection and decides on payer claims, 3.2.1." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "boleto:exc.payer-claim", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.cash-payment-ceiling", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.company-bank-file-standard", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.destination-liable-for-slip-errors", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.partial-payment-settings", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.payer-claim", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.proposta-disclosures", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.proposta-payment-is-acceptance", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.proposta-prior-wish", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.rights-and-duties-sources", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.write-off", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "boleto:role.convention-governance", "id": "role.convention-governance", "rail": "boleto", "class": "Role", "name": "Convention governance structure", "summary": "The body the participants must set up to govern the convention under Res. 443 art. 20. National associations hold its seats and votes in proportion to the annual boleto volume of their members, no association may hold more than half the votes, and changes pass by simple majority before BCB approval. The 2021 convention was signed by ABBC, ABBI, ABECS and Febraban, with CIP as processor.", "kind": "authority", "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 20 §3; art. 21", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "boleto:src.convencao-cobranca-2021", "section": "preamble and signatures", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 arts. 20 and 21 as amended by Res. BCB 467/2025; 2021 convention preamble; read 2026-09-19. Which associations sit today is published by the BCB and was not read [Unverified].", "confidence": "medium" }, "currency": { "effective_since": "2025-04-30", "effective_to": null, "effective_note": "Drafted 2026-09-19. The governance rules in art. 21 §§1 to 7 were added by Res. BCB 467 of 2025-04-30; the date is that resolution's date, and its own start date was not read [Unverified]. The lines from the 2021 convention carry its own doubt: The 2021 convention entered into force on 2021-02-10 (art. 36) and was made under Circular 3.598/2012, which Res. BCB 443 revoked; Res. 443 art. 20 §4 required changes to the convention to be submitted to the BCB, and whether a later edition replaces the 2021 text was not established [Unverified].", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the governance structure's seat and vote allocation, the 50 percent cap and simple-majority-then-BCB-approval process, art. 20 par. 3 and art. 21." }, { "source": "boleto:src.convencao-cobranca-2021", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the preamble signatories ABBC, ABBI, ABECS and Febraban, with CIP as processor." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "boleto:rule.convention-delegation", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.convention-governance", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "boleto:role.destination-institution", "id": "role.destination-institution", "rail": "boleto", "class": "Role", "name": "Destination institution (instituição destinatária)", "summary": "The authorised institution the receiving institution owes, and which in turn owes the beneficiary. It is the issuer, except that a dynamic boleto's destination can change when its asset is traded. It sends any devolução or acerto de diferença back to the receiving institution through the system that settled the original.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 3, VII and §1; art. 5, I, b; art. 18", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 arts. 3, 5 and 18, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 from Res. BCB 443, consolidated version 3.0. The date is the day the resolution entered into force (art. 26).", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the definition of instituicao destinataria, that it equals the issuer for common cobranca, proposta and deposito boletos, and its role in devolucao, arts. 3, 5 and 18." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "boleto:exc.interbank-devolucao", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "boleto:exc.interbank-devolucao", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.barcode-standard", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.cash-payment-ceiling", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.central-database-registration", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.destination-liable-for-slip-errors", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.devolucao-convention-grounds", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.devolucao-next-business-day", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.devolucao-same-system", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.direct-or-represented-settlement", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.interbank-receipt-data-informative", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.netting-route-below-threshold", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.non-business-day-due-date", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.nonconforming-payment-reversal-attempt", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.participation-eligibility", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.rights-and-duties-sources", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.siloc-file-exchange", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.str-transfers-by-noon", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "boleto:role.issuing-institution", "id": "role.issuing-institution", "rail": "boleto", "class": "Role", "name": "Issuing institution (instituição emissora)", "summary": "An institution authorised by the BCB that issues boletos at the beneficiary's request. For common cobrança, proposal and deposit boletos it is also the destination institution. It must choose the dynamic modality where the beneficiary has an asset-recording contract, vet any third-party enabler, and run risk management over species, the soundness of the billed obligation and monitoring.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 3, V and §1; arts. 11, 14 and 24", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 arts. 3, 11, 14 and 24, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 from Res. BCB 443, consolidated version 3.0. The date is the day the resolution entered into force (art. 26).", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the definition of instituicao emissora and its duties on dynamic issuance, enabler vetting and risk management, arts. 3, 11, 14 and 24." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "boleto:exc.entry-rejection", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "boleto:exc.entry-rejection", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.company-bank-file-standard", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.dynamic-asset-links", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.electronic-presentment-consent", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.enabler-due-diligence", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.entry-rejection", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.issuer-must-issue-dynamic", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.issuer-risk-management", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.minimum-content", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.partial-payment-settings", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.participation-eligibility", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.payer-claim", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.pix-qr-on-boleto", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.proposta-disclosures", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.proposta-prior-wish", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.rights-and-duties-sources", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.write-off", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "boleto:role.nuclea", "id": "role.nuclea", "rail": "boleto", "class": "Role", "name": "Núclea (CIP S.A.)", "summary": "Trade name of CIP S.A. CIP began as a non-profit civil association, the Câmara Interbancária de Pagamentos, which the 2021 convention names as its processor, and created Núclea. It runs SILOC, the deferred net settlement system that clears boletos below the VR-Boleto (and card and ATM items), and the central boleto database, which it calls the Plataforma Centralizada de Recebíveis (PCR). For dynamic boletos, Res. 443 has the operator of the boleto settlement system exchange data with the asset registries' shared platform and police the dynamic issuance rule.", "kind": "operator", "relations": [ { "type": "sourced_from", "to": "boleto:src.nuclea-pfmi-report-v4", "section": "sections 2 and 4, a.2 and b.6 (pp. 3 to 5)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "boleto:src.nuclea-siloc", "section": "O que é o SILOC; FAQ", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "boleto:src.convencao-cobranca-2021", "section": "preamble, recital (iii)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 12, §1, I; art. 12-A", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Núclea PFMI report v4 sections 2 and 4; SILOC page; 2021 convention preamble; Res. BCB 443 arts. 12 and 12-A; read 2026-09-19. Res. 443 speaks of the operator of the settlement system without naming it; that this is Núclea rests on the other three sources.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: SILOC has run since 2004 per Núclea, and the operator duties in Res. 443 apply from its entry into force", "effective_to": null, "effective_note": "Drafted 2026-09-19 from Núclea's public pages and report, the 2021 convention and Res. BCB 443, which entered into force on 2025-02-03 (art. 26); arts. 12 §1 and 12-A are as amended by Res. BCB 515/2025. The lines from the 2021 convention carry its own doubt: The 2021 convention entered into force on 2021-02-10 (art. 36) and was made under Circular 3.598/2012, which Res. BCB 443 revoked; Res. 443 art. 20 §4 required changes to the convention to be submitted to the BCB, and whether a later edition replaces the 2021 text was not established [Unverified].", "source_edition": "Núclea, Relatório Divulgação PFMI CPSS-IOSCO, version 4 (2026 self-assessment, valid to 2028-07-10), read 2026-09-19; Núclea SILOC product page, live page with a footer dated 2025, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.nuclea-pfmi-report-v4", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms Nuclea (CIP S.A.) runs SILOC and the Plataforma Centralizada de Recebiveis, sections 2 and 4." }, { "source": "boleto:src.nuclea-siloc", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms Nuclea operates SILOC for compensation and settlement of boletos, cards and ATM items." }, { "source": "boleto:src.convencao-cobranca-2021", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the convention names CIP as the entity chosen to run SILOC and the central database, preamble recital iii." }, { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the settlement system operator's data-sharing and rule-enforcement duties for dynamic boletos, art. 12 par. 1 and art. 12-A." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "boleto:rule.central-database-registration", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.direct-or-represented-settlement", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.dynamic-always-nets", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.dynamic-asset-links", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.electronic-presentment-consent", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.issuer-must-issue-dynamic", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.siloc-file-exchange", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.siloc-finality-at-transfer", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.siloc-net-central-bank-money", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.siloc-settlement-default", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.siloc-settlement-timing", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "boleto:role.payer", "id": "role.payer", "rail": "boleto", "class": "Role", "name": "Payer (pagador)", "summary": "The person or company that pays the boleto: the debtor of a billed obligation, someone accepting an offer or proposal by paying a boleto de proposta, or an account holder funding their own account with a boleto de depósito e aporte. Formerly called sacado. The payer can pay at any receiving institution; the regulation gives it no right to reverse a paid boleto.", "kind": "party", "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 3, IV", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 art. 3, IV, read 2026-09-19. That no reversal right exists is [Inference] from its absence in Res. 443.", "confidence": "medium" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 from Res. BCB 443, consolidated version 3.0. The date is the day the resolution entered into force (art. 26).", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the definition of pagador as debtor, offer-acceptor or account holder, art. 3, IV; no payer reversal right is stated in the resolution." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "boleto:exc.payer-claim", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.proposta-payment-is-acceptance", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "boleto:role.receiving-institution", "id": "role.receiving-institution", "rail": "boleto", "class": "Role", "name": "Receiving institution (instituição recebedora)", "summary": "The authorised institution where the payer pays. It takes the funds on the boleto's terms and owes them to the destination institution: over STR the same day at or above the VR-Boleto, otherwise by netting or STR as it chooses. It may hold an STR transfer while it checks signs of irregularity. Under the 2021 convention it passes on the database's data exactly and repays the payer after a devolução.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 3, VI; art. 16", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "boleto:src.convencao-cobranca-2021", "section": "arts. 30 and 32", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 arts. 3 and 16; 2021 convention arts. 30 and 32; read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 from Res. BCB 443, consolidated version 3.0. The date is the day the resolution entered into force (art. 26). The lines from the 2021 convention carry its own doubt: The 2021 convention entered into force on 2021-02-10 (art. 36) and was made under Circular 3.598/2012, which Res. BCB 443 revoked; Res. 443 art. 20 §4 required changes to the convention to be submitted to the BCB, and whether a later edition replaces the 2021 text was not established [Unverified].", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the definition of instituicao recebedora, its settlement duty to the destination institution, and the irregularity hold, art. 3 and art. 16." }, { "source": "boleto:src.convencao-cobranca-2021", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the receiving institution's duty to reproduce the central database's data exactly and to repay the payer after a devolucao, arts. 30 and 32." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "boleto:exc.interbank-devolucao", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.cash-payment-ceiling", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.central-database-registration", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.devolucao-convention-grounds", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.devolucao-next-business-day", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.devolucao-same-system", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.direct-or-represented-settlement", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.interbank-receipt-data-informative", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.netting-route-below-threshold", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.non-business-day-due-date", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.nonconforming-payment-reversal-attempt", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.participation-eligibility", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.receiving-liable-for-data-reproduction", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.rights-and-duties-sources", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.siloc-file-exchange", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.str-60-minute-send", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.str-hold-for-irregularity", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.str-route-large-boletos", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "boleto:role.rights-holder", "id": "role.rights-holder", "rail": "boleto", "class": "Role", "name": "Rights holder (titular de direito)", "summary": "The fiduciary or actual holder of the financial asset linked to a dynamic boleto. When the asset is traded, the system where it is recorded or registered instructs the change, and the rights holder takes the beneficiary's place on the boleto, possibly with a new destination institution.", "kind": "party", "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 3, III; art. 5, I, b and §1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 art. 3, III and art. 5, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 from Res. BCB 443, consolidated version 3.0. The date is the day the resolution entered into force (art. 26).", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the definition of titular de direito and the beneficiary-replacement mechanism on a traded asset, art. 3, III and art. 5." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:role.third-party-enabler", "id": "role.third-party-enabler", "rail": "boleto", "class": "Role", "name": "Third-party enabler (terceiro habilitador)", "summary": "A company that, under contract with an issuing institution and in its name, onboards beneficiaries to use boletos. It is named on the boleto. The issuer must check it meets technical, cyber-security, reputation and anti-money-laundering expectations and must be able to see the documents identifying each beneficiary it brings in.", "kind": "service_provider", "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 3, II; art. 7, II; art. 14", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 arts. 3, 7 and 14, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 from Res. BCB 443, consolidated version 3.0. The date is the day the resolution entered into force (art. 26).", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the definition of terceiro habilitador and the issuer's due-diligence and document-access duties, art. 3, II and art. 14." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "boleto:rule.enabler-due-diligence", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "boleto:rule.barcode-standard", "id": "rule.barcode-standard", "rail": "boleto", "class": "Rule", "name": "The boleto barcode and typed line", "statement": "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].", "rests_on": "guidance", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "boleto:src.febraban-cnab240-v11-0", "section": "G063 (p. 208)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "boleto:src.convencao-cobranca-2021", "section": "art. 14", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.destination-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "CNAB240 v11.0 G063 and 2021 convention art. 14, read 2026-09-19; Carta-Circular 2.926 not read.", "confidence": "medium" }, "currency": { "effective_since": "2021-02-10", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the 2021 convention. The 2021 convention entered into force on 2021-02-10 (art. 36) and was made under Circular 3.598/2012, which Res. BCB 443 revoked; Res. 443 art. 20 §4 required changes to the convention to be submitted to the BCB, and whether a later edition replaces the 2021 text was not established [Unverified].", "source_edition": "Convenção entre instituições participantes do SFN sobre a emissão, apresentação, processamento e liquidação interbancária dos boletos de pagamento, FB-0061/2021, signed 2021-02-05, in force from 2021-02-10; PDF of 39 pages read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.febraban-cnab240-v11-0", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the G063 barcode field traces to BCB Carta-Circular 2.926 of 2000-07-25, layout CADOC 24044-4." }, { "source": "boleto:src.convencao-cobranca-2021", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the barcode and the typed line must carry exactly the same data, art. 14." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:rule.boleto-paid-through-other-arrangement", "id": "rule.boleto-paid-through-other-arrangement", "rail": "boleto", "class": "Rule", "name": "A boleto paid through another BCB arrangement follows that arrangement's rules", "statement": "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].", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 6 §2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "boleto:src.febraban-cnab240-v11-0", "section": "C010 values P and Q (pp. 172 to 173); C047 list C, code 61 (p. 182)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "pix:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 art. 6 §2 and CNAB240 v11.0 C010 and C047, read 2026-09-19. The application to Pix is [Inference].", "confidence": "medium" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 from Res. BCB 443, consolidated version 3.0. The date is the day the resolution entered into force (art. 26).", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms a boleto may be presented so it can be paid through another BCB-authorised or operated arrangement, art. 6 par. 2." }, { "source": "boleto:src.febraban-cnab240-v11-0", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms distribution codes P and Q for a boleto registered with a Pix QR code and occurrence C047 list C code 61 for a title settled via Pix." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:rule.cash-payment-ceiling", "id": "rule.cash-payment-ceiling", "rail": "boleto", "class": "Rule", "name": "No cash payment of boletos of R$10,000.00 or more", "statement": "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.", "rests_on": "rule", "facet": "limits", "parameters": { "limit": { "amount": 10000, "currency": "BRL", "per": "entry", "text": "cash accepted only below R$10,000.00 per boleto" } }, "relations": [ { "type": "sourced_from", "to": "boleto:src.convencao-cobranca-2021", "section": "arts. 18 to 21", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.receiving-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.destination-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.beneficiary", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "2021 convention arts. 18 to 21, read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2018-05-28", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the 2021 convention, which dates the cash rule from 2018-05-28 (art. 18). The 2021 convention entered into force on 2021-02-10 (art. 36) and was made under Circular 3.598/2012, which Res. BCB 443 revoked; Res. 443 art. 20 §4 required changes to the convention to be submitted to the BCB, and whether a later edition replaces the 2021 text was not established [Unverified].", "source_edition": "Convenção entre instituições participantes do SFN sobre a emissão, apresentação, processamento e liquidação interbancária dos boletos de pagamento, FB-0061/2021, signed 2021-02-05, in force from 2021-02-10; PDF of 39 pages read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.convencao-cobranca-2021", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the R10,000.00 cash payment ceiling from 2018-05-28, the anti-fragmentation rule, and the R2,000.00 payer identification threshold, arts. 18 to 21." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:rule.central-database-registration", "id": "rule.central-database-registration", "rail": "boleto", "class": "Rule", "name": "Every boleto is registered in the central database before it is presented", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 3, VIII and §2", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "boleto:src.convencao-cobranca-2021", "section": "arts. 5, 11 and 17 §§1 and 2", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "boleto:src.nuclea-pfmi-report-v4", "section": "section 4, b.6 (p. 5)", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "boleto:src.nuclea-siloc-regulamento", "section": "art. 1, the definition of a partially suspended participant; art. 22 and its §1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.destination-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.receiving-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.nuclea", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 art. 3; 2021 convention arts. 5, 11 and 17; Núclea PFMI report v4 section 4; read 2026-09-19. Núclea SILOC operating rulebook, edition 02.01.2026, arts. 1 and 22, read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Redrafted 2026-09-20 to add what Núclea's SILOC operating rulebook, version 4.0 of 2026-01-02, makes of database membership. The rest was drafted 2026-09-19 from Res. BCB 443, consolidated version 3.0, whose date is the day it entered into force (art. 26). The lines from the 2021 convention carry its own doubt: The 2021 convention entered into force on 2021-02-10 (art. 36) and was made under Circular 3.598/2012, which Res. BCB 443 revoked; Res. 443 art. 20 §4 required changes to the convention to be submitted to the BCB, and whether a later edition replaces the 2021 text was not established [Unverified].", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19; Convenção entre instituições participantes do SFN sobre a emissão, apresentação, processamento e liquidação interbancária dos boletos de pagamento, FB-0061/2021, signed 2021-02-05, in force from 2021-02-10; PDF of 39 pages 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": "boleto:src.nuclea-siloc-regulamento", "checked_on": "2026-09-20", "checked_by": "validator-boleto-2026-09-20", "notes": "Confirms the SILOC rulebook partially suspends from SILOC, for boleto transfers only, any participant that has not joined the central database, drops a participant that later leaves the database out of SILOC for boletos at the same time, and suspends or excludes a participant from the database the moment SILOC suspends or excludes it." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:rule.company-bank-file-standard", "id": "rule.company-bank-file-standard", "rail": "boleto", "class": "Rule", "name": "Company-to-bank files: the Febraban CNAB240 standard", "statement": "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.", "rests_on": "guidance", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "boleto:src.febraban-cnab240-v11-0", "section": "1.1 (p. 6); 3.2.1 events and closing note (pp. 66 to 67); 5.2 (p. 252)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.issuing-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.beneficiary", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "CNAB240 v11.0 1.1, 3.2.1 and 5.2, read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-11", "effective_to": null, "effective_note": "Drafted 2026-09-19 from CNAB240 version 11.0, which Febraban marks preliminary (5.2). The date is that edition's date; the fields and codes cited are older, and when each first appeared was not traced.", "source_edition": "Layout Padrão Febraban 240 posições, version 11.0 of 2026-09-11, marked preliminary; PDF of 260 pages, relevant sections read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.febraban-cnab240-v11-0", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the standard covers company remittance and bank return files for cobranca, the detail segments used, and that version 11.0 is marked preliminary, 1.1, 3.2.1 and 5.2." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:rule.convention-delegation", "id": "rule.convention-delegation", "rail": "boleto", "class": "Rule", "name": "What the participants' convention governs", "statement": "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].", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 20, caput and §§1 and 2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "boleto:src.convencao-cobranca-2021", "section": "arts. 4 and 36", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "boleto:src.febraban-nova-plataforma-boletos", "section": "link to Convenção da Cobrança of 05.02.2021", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.convention-governance", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 art. 20; 2021 convention arts. 4 and 36; Febraban's page linking the convention; read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 from Res. BCB 443, consolidated version 3.0. The date is the day the resolution entered into force (art. 26). The lines from the 2021 convention carry its own doubt: The 2021 convention entered into force on 2021-02-10 (art. 36) and was made under Circular 3.598/2012, which Res. BCB 443 revoked; Res. 443 art. 20 §4 required changes to the convention to be submitted to the BCB, and whether a later edition replaces the 2021 text was not established [Unverified].", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19; Convenção entre instituições participantes do SFN sobre a emissão, apresentação, processamento e liquidação interbancária dos boletos de pagamento, FB-0061/2021, signed 2021-02-05, in force from 2021-02-10; PDF of 39 pages read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the convention governs standards, procedures, hours, rights and duties, devolucao timing and the fee model, art. 20." }, { "source": "boleto:src.convencao-cobranca-2021", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the 2021 convention was made under the regulation Res. 443 later revoked, and its indefinite term, arts. 4 and 36." }, { "source": "boleto:src.febraban-nova-plataforma-boletos", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms Febraban's page links the Convencao da Cobranca of 05.02.2021 as the file in force." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:rule.convention-governance", "id": "rule.convention-governance", "rail": "boleto", "class": "Rule", "name": "How the convention is changed", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 20 §§3 and 4; art. 21 §§1 to 7", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.convention-governance", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.bcb", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 arts. 20 and 21 as amended by Res. BCB 467/2025, read 2026-09-19. The BCB's publication of the associations and votes was not read. Decision-points readings are capped at medium.", "confidence": "medium" }, "currency": { "effective_since": "2025-04-30", "effective_to": null, "effective_note": "Drafted 2026-09-19. Art. 20 §§3 and 4 and art. 21 §§1 to 7 are in the wording given or added by Res. BCB 467 of 2025-04-30; the date is that resolution's date, and its own start date was not read [Unverified].", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the simple-majority-then-BCB-approval process and the vote allocation, cap and publication duties, art. 20 par. 3 and 4 and art. 21 par. 1 to 7." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:rule.destination-liable-for-slip-errors", "id": "rule.destination-liable-for-slip-errors", "rail": "boleto", "class": "Rule", "name": "The destination institution answers for defective slips and failed registration", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "boleto:src.convencao-cobranca-2021", "section": "arts. 13, 16 and 17 §3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.destination-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.beneficiary", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "2021 convention arts. 13, 16 and 17, read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2021-02-10", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the 2021 convention. The 2021 convention entered into force on 2021-02-10 (art. 36) and was made under Circular 3.598/2012, which Res. BCB 443 revoked; Res. 443 art. 20 §4 required changes to the convention to be submitted to the BCB, and whether a later edition replaces the 2021 text was not established [Unverified].", "source_edition": "Convenção entre instituições participantes do SFN sobre a emissão, apresentação, processamento e liquidação interbancária dos boletos de pagamento, FB-0061/2021, signed 2021-02-05, in force from 2021-02-10; PDF of 39 pages read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.convencao-cobranca-2021", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the destination institution's liability for defective slips, the validation duty and the registration-failure liability, arts. 13, 16 and 17 par. 3." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:rule.devolucao-convention-grounds", "id": "rule.devolucao-convention-grounds", "rail": "boleto", "class": "Rule", "name": "Grounds and deadlines for devolução under the 2021 convention", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "boleto:src.convencao-cobranca-2021", "section": "arts. 24 §3, 25 §2, 31 and 32; annexes VI and VII", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.destination-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.receiving-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "boleto:exc.interbank-devolucao", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "2021 convention arts. 24, 25, 31 and 32 and annexes VI and VII, read 2026-09-19. The reason codes that carry these grounds are in SILOC's and the central database's manuals, not read.", "confidence": "medium" }, "currency": { "effective_since": "2021-02-10", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the 2021 convention. The 2021 convention entered into force on 2021-02-10 (art. 36) and was made under Circular 3.598/2012, which Res. BCB 443 revoked; Res. 443 art. 20 §4 required changes to the convention to be submitted to the BCB, and whether a later edition replaces the 2021 text was not established [Unverified].", "source_edition": "Convenção entre instituições participantes do SFN sobre a emissão, apresentação, processamento e liquidação interbancária dos boletos de pagamento, FB-0061/2021, signed 2021-02-05, in force from 2021-02-10; PDF of 39 pages read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.convencao-cobranca-2021", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the automatable devolucao grounds and deadline in annex VI, the receiving-institution request in annex VII, and the one-business-day payer repayment, arts. 24 par. 3, 25 par. 2, 31 and 32." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "boleto:exc.interbank-devolucao", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "boleto:rule.devolucao-next-business-day", "id": "rule.devolucao-next-business-day", "rail": "boleto", "class": "Rule", "name": "Automatable devoluções and adjustments by the next business day", "statement": "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.", "rests_on": "rule", "facet": "return", "parameters": { "time_window": { "count": 1, "unit": "business_day", "from": "settlement_date", "text": "by the business day after settlement" } }, "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 18 §1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.destination-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.receiving-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "boleto:exc.interbank-devolucao", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 art. 18 §1, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 from Res. BCB 443, consolidated version 3.0. The date is the day the resolution entered into force (art. 26).", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms an automatable devolucao or acerto de diferenca must be made by the business day after settlement, art. 18 par. 1." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "boleto:exc.interbank-devolucao", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "boleto:rule.devolucao-same-system", "id": "rule.devolucao-same-system", "rail": "boleto", "class": "Rule", "name": "Devoluções and adjustments run through the system that settled the original", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 18", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.destination-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.receiving-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "boleto:exc.interbank-devolucao", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "boleto:rule.str-transfers-by-noon", "note": "The deadline on the STR route this record sends a devolucao down. That record is art. 18 paragraph 2 and the 2021 convention, the noon cut-off; this one is art. 18, which system must be used.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 art. 18, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 from Res. BCB 443, consolidated version 3.0. The date is the day the resolution entered into force (art. 26).", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms devolucao and acerto de diferenca use the same system that settled the original obligation, art. 18." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "boleto:exc.interbank-devolucao", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.str-transfers-by-noon", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "boleto:rule.direct-or-represented-settlement", "id": "rule.direct-or-represented-settlement", "rail": "boleto", "class": "Rule", "name": "Settling directly or through a representative", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 15 and sole paragraph", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "boleto:src.nuclea-siloc", "section": "FAQ, who may take part and certification", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.receiving-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.destination-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.nuclea", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 art. 15 and Núclea SILOC page FAQ, read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 from Res. BCB 443, consolidated version 3.0. The date is the day the resolution entered into force (art. 26). The SILOC admission line rests on Núclea's live page.", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19; Núclea SILOC product page, live page with a footer dated 2025, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms direct settlement requires participation in STR and the netting system, otherwise a representative institution is hired, art. 15." }, { "source": "boleto:src.nuclea-siloc", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms SILOC admits BCB-authorised institutions holding a settlement or reserve account, after adherence and mandatory testing." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:rule.dynamic-always-nets", "id": "rule.dynamic-always-nets", "rail": "boleto", "class": "Rule", "name": "Dynamic boletos always settle by multilateral netting", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 17 and §§1 and 2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.nuclea", "note": "[Inference] Res. 443 speaks of the settlement flow without naming an operator; SILOC is the netting system the convention and Núclea name.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "boleto:txn.cobranca-dinamico", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 art. 17, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 from Res. BCB 443, consolidated version 3.0. The date is the day the resolution entered into force (art. 26).", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms dynamic boletos always settle by multilateral netting regardless of amount, and the asset-system data flow duties, art. 17 par. 1 and 2." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:rule.dynamic-asset-links", "id": "rule.dynamic-asset-links", "rail": "boleto", "class": "Rule", "name": "Dynamic boletos and the asset registries", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "arts. 12, 12-A and 23", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "boleto:src.bcb-instrucao-normativa-611", "section": "arts. 1 to 3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.issuing-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.nuclea", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "boleto:txn.cobranca-dinamico", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 arts. 12, 12-A and 23 as amended by Res. BCB 515/2025; IN BCB 611; read 2026-09-19. The BCB Comunicados that set the schedules were not read.", "confidence": "high" }, "currency": { "effective_since": "2025-10-21", "effective_to": null, "effective_note": "Drafted 2026-09-19. Arts. 12 and 12-A read here are as amended and added by Res. BCB 515 of 2025-10-21; the date is that resolution's date, and its own start date was not read [Unverified]. IN 611 is in force from 2025-04-30.", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19; Instrução Normativa BCB nº 611 of 2025-04-22, version 1.0, in force 2025-04-30, read with its supporting Nota 238/2025 on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the settlement-system operator's data flow with the asset registries' shared platform, the equal-terms and deadline duties, and the 180-day phase-in schedule, arts. 12, 12-A and 23." }, { "source": "boleto:src.bcb-instrucao-normativa-611", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the two eligible asset types and the schedule agreed between the settlement operator and the asset systems, arts. 1 to 3." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:rule.electronic-presentment-consent", "id": "rule.electronic-presentment-consent", "rail": "boleto", "class": "Rule", "name": "Electronic presentment needs the payer's consent", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 6 and §1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "boleto:src.cip-dda-termo-adesao", "section": "clause 1 and clause 2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.issuing-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.nuclea", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 art. 6, 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 add what the DDA membership terms say DDA is. The date stays the day Res. BCB 443 entered into force (art. 26); the consent line was drafted 2026-09-19 from its consolidated version 3.0. The DDA terms were signed 2017-10-02 by CIP, which has since renamed itself Núclea, and DDA's own convention and manual of operations, which govern it, are not published; whether the description still holds unchanged was not established [Unverified]. That DDA is not a standing debit authority is read off that description rather than stated in it [Inference].", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19; Termo de Adesão ao Sistema de Débito Direto Autorizado DDA, signed 2017-10-02, scanned PDF of 4 pages read as page images 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-20", "checked_by": "validator-boleto-2026-09-20", "notes": "Confirms a boleto follows the model the convention sets, may be presented on paper or electronically, and that the issuing institution must obtain the payer's agreement before presenting it electronically." }, { "source": "boleto:src.cip-dda-termo-adesao", "checked_on": "2026-09-20", "checked_by": "validator-boleto-2026-09-20", "notes": "Confirms DDA is described as an electronic system for presenting and consulting boletos, a repository of collection data built from data participating institutions send and draw on and managed by the CIP, now Núclea, and that joining DDA requires already being a SILOC participant." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:rule.enabler-due-diligence", "id": "rule.enabler-due-diligence", "rail": "boleto", "class": "Rule", "name": "Checks an issuer owes on a third-party enabler", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 14 and sole paragraph", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.issuing-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.third-party-enabler", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 art. 14, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 from Res. BCB 443, consolidated version 3.0. The date is the day the resolution entered into force (art. 26).", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the issuer's due diligence over a contracted enabler and the contract's document-access requirement, art. 14." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:rule.entry-rejection", "id": "rule.entry-rejection", "rail": "boleto", "class": "Rule", "name": "The issuing bank may reject a title at entry", "statement": "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.", "rests_on": "guidance", "facet": "return", "relations": [ { "type": "sourced_from", "to": "boleto:src.febraban-cnab240-v11-0", "section": "3.2.1 events (p. 66) and closing note (p. 67); C044 (p. 177); C047 list A (pp. 179 to 181)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "boleto:src.convencao-cobranca-2021", "section": "art. 11 §2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.issuing-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "boleto:exc.entry-rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "CNAB240 v11.0 3.2.1, C044 and C047; 2021 convention art. 11 §2; read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-11", "effective_to": null, "effective_note": "Drafted 2026-09-19 from CNAB240 version 11.0, which Febraban marks preliminary (5.2). The date is that edition's date; the fields and codes cited are older, and when each first appeared was not traced. The lines from the 2021 convention carry its own doubt: The 2021 convention entered into force on 2021-02-10 (art. 36) and was made under Circular 3.598/2012, which Res. BCB 443 revoked; Res. 443 art. 20 §4 required changes to the convention to be submitted to the BCB, and whether a later edition replaces the 2021 text was not established [Unverified].", "source_edition": "Layout Padrão Febraban 240 posições, version 11.0 of 2026-09-11, marked preliminary; PDF of 260 pages, relevant sections read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.febraban-cnab240-v11-0", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms movement codes 02 and 03 and the list A occurrence reasons, 3.2.1, C044 and C047." }, { "source": "boleto:src.convencao-cobranca-2021", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms a boleto may be presented only after registration in the central database, art. 11 par. 2." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "boleto:exc.entry-rejection", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "boleto:rule.interbank-receipt-data-informative", "id": "rule.interbank-receipt-data-informative", "rail": "boleto", "class": "Rule", "name": "Early payment data given to a beneficiary is informative only", "statement": "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.", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "boleto:src.convencao-cobranca-2021", "section": "art. 27 §§4, 5 and 7", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.destination-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.receiving-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "2021 convention art. 27, read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2021-02-10", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the 2021 convention. The 2021 convention entered into force on 2021-02-10 (art. 36) and was made under Circular 3.598/2012, which Res. BCB 443 revoked; Res. 443 art. 20 §4 required changes to the convention to be submitted to the BCB, and whether a later edition replaces the 2021 text was not established [Unverified].", "source_edition": "Convenção entre instituições participantes do SFN sobre a emissão, apresentação, processamento e liquidação interbancária dos boletos de pagamento, FB-0061/2021, signed 2021-02-05, in force from 2021-02-10; PDF of 39 pages read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.convencao-cobranca-2021", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms early interbank receipt data is informative only, and the baixa operacional and baixa efetiva sequence, art. 27 par. 4, 5 and 7." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:rule.issuer-must-issue-dynamic", "id": "rule.issuer-must-issue-dynamic", "rail": "boleto", "class": "Rule", "name": "When the issuer must issue a dynamic boleto", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 11 and §§1 and 2; art. 12-A, I", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.issuing-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.nuclea", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "boleto:txn.cobranca-dinamico", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "boleto:txn.cobranca-comum", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 arts. 11 and 12-A, read 2026-09-19. Decision-points readings are capped at medium.", "confidence": "medium" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 from Res. BCB 443, consolidated version 3.0. The date is the day the resolution entered into force (art. 26).", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the issuer must issue dynamic when the beneficiary has an asset-recording contract, and the non-discrimination, pricing-parity and no-exclusivity duties, art. 11 par. 1 and 2 and art. 12-A, I." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:rule.issuer-risk-management", "id": "rule.issuer-risk-management", "rail": "boleto", "class": "Rule", "name": "The issuer's risk management duties", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 24", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.issuing-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 art. 24, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 from Res. BCB 443, consolidated version 3.0. The date is the day the resolution entered into force (art. 26).", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the issuer's risk management duties on species use, obligation soundness and information monitoring, art. 24." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:rule.minimum-content", "id": "rule.minimum-content", "rail": "boleto", "class": "Rule", "name": "What every boleto must show", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 7 and sole paragraph; art. 10 and sole paragraph", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.issuing-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 arts. 7 and 10, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 from Res. BCB 443, consolidated version 3.0. The date is the day the resolution entered into force (art. 26).", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the minimum content for every boleto and the additional dynamic-boleto content, art. 7 and art. 10." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:rule.netting-route-below-threshold", "id": "rule.netting-route-below-threshold", "rail": "boleto", "class": "Rule", "name": "Below the VR-Boleto: multilateral netting or STR, at the receiving institution's choice", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 16, II and §3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "boleto:src.convencao-cobranca-2021", "section": "art. 27, I and II and §2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.receiving-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.destination-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "boleto:txn.cobranca-comum", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "boleto:txn.proposta", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "boleto:txn.deposito-e-aporte", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 art. 16, II and §3; 2021 convention art. 27; read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 from Res. BCB 443, consolidated version 3.0. The date is the day the resolution entered into force (art. 26). The lines from the 2021 convention carry its own doubt: The 2021 convention entered into force on 2021-02-10 (art. 36) and was made under Circular 3.598/2012, which Res. BCB 443 revoked; Res. 443 art. 20 §4 required changes to the convention to be submitted to the BCB, and whether a later edition replaces the 2021 text was not established [Unverified].", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19; Convenção entre instituições participantes do SFN sobre a emissão, apresentação, processamento e liquidação interbancária dos boletos de pagamento, FB-0061/2021, signed 2021-02-05, in force from 2021-02-10; PDF of 39 pages read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms a boleto below the VR-Boleto may net or route via STR at the receiving institution's choice, art. 16, II and par. 3." }, { "source": "boleto:src.convencao-cobranca-2021", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms SILOC as the netting system named for the below-threshold route, art. 27, I and II and par. 2." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:rule.non-business-day-due-date", "id": "rule.non-business-day-due-date", "rail": "boleto", "class": "Rule", "name": "A due date on a non-business day moves to the next business day without charges", "statement": "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.", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "boleto:src.convencao-cobranca-2021", "section": "art. 22", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.receiving-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.destination-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "2021 convention art. 22, read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2021-02-10", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the 2021 convention. The 2021 convention entered into force on 2021-02-10 (art. 36) and was made under Circular 3.598/2012, which Res. BCB 443 revoked; Res. 443 art. 20 §4 required changes to the convention to be submitted to the BCB, and whether a later edition replaces the 2021 text was not established [Unverified].", "source_edition": "Convenção entre instituições participantes do SFN sobre a emissão, apresentação, processamento e liquidação interbancária dos boletos de pagamento, FB-0061/2021, signed 2021-02-05, in force from 2021-02-10; PDF of 39 pages read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.convencao-cobranca-2021", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms a boleto due on a non-business day may be paid the next business day with no interest or fine, art. 22." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:rule.nonconforming-payment-reversal-attempt", "id": "rule.nonconforming-payment-reversal-attempt", "rail": "boleto", "class": "Rule", "name": "Payment taken out of conformity: a reversal attempt through the receiving institution", "statement": "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.", "rests_on": "rule", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "boleto:src.convencao-cobranca-2021", "section": "art. 34, I to III and §§1, 3 and 5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.receiving-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.destination-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "boleto:exc.interbank-devolucao", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "2021 convention art. 34, read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2021-02-10", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the 2021 convention. The 2021 convention entered into force on 2021-02-10 (art. 36) and was made under Circular 3.598/2012, which Res. BCB 443 revoked; Res. 443 art. 20 §4 required changes to the convention to be submitted to the BCB, and whether a later edition replaces the 2021 text was not established [Unverified].", "source_edition": "Convenção entre instituições participantes do SFN sobre a emissão, apresentação, processamento e liquidação interbancária dos boletos de pagamento, FB-0061/2021, signed 2021-02-05, in force from 2021-02-10; PDF of 39 pages read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.convencao-cobranca-2021", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the non-conformity reversal-attempt procedure between receiving and destination institution and the five-year claim window, art. 34." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "boleto:exc.interbank-devolucao", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "boleto:rule.partial-payment-settings", "id": "rule.partial-payment-settings", "rail": "boleto", "class": "Rule", "name": "Partial payment and minimum and maximum amounts are set per title", "statement": "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].", "rests_on": "guidance", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "boleto:src.febraban-cnab240-v11-0", "section": "C044 (pp. 177 to 178); C047 list A (p. 181)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.issuing-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.beneficiary", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "CNAB240 v11.0 C044 and C047, read 2026-09-19. A bank-to-client file standard, not a rule of the arrangement.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-11", "effective_to": null, "effective_note": "Drafted 2026-09-19 from CNAB240 version 11.0, which Febraban marks preliminary (5.2). The date is that edition's date; the fields and codes cited are older, and when each first appeared was not traced.", "source_edition": "Layout Padrão Febraban 240 posições, version 11.0 of 2026-09-11, marked preliminary; PDF of 260 pages, relevant sections read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.febraban-cnab240-v11-0", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms movement codes 64 and 65 for minimum and maximum value changes, and C047 list A codes A9, B1, B4 and B5 for partial-payment and value-limit settings." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:rule.participation-eligibility", "id": "rule.participation-eligibility", "rail": "boleto", "class": "Rule", "name": "Who may take part, and in which roles", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 2; art. 3 §1; art. 20 §1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.issuing-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.receiving-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.destination-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 arts. 2, 3 and 20, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 from Res. BCB 443, consolidated version 3.0. The date is the day the resolution entered into force (art. 26).", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the participation categories by account-offering status, the destination-equals-issuer rule and the non-represented-institution acceptance duty, art. 2, art. 3 par. 1 and art. 20 par. 1." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:rule.payer-claim", "id": "rule.payer-claim", "rail": "boleto", "class": "Rule", "name": "Payer claim: the beneficiary decides", "statement": "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].", "rests_on": "guidance", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "boleto:src.febraban-cnab240-v11-0", "section": "3.2.1, information flow (p. 65) and payer claim events (p. 67)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.beneficiary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.issuing-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "boleto:exc.payer-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "CNAB240 v11.0 3.2.1, read 2026-09-19; Res. BCB 443 read in full for the absence of a reversal duty. Decision-points readings are capped at medium.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-11", "effective_to": null, "effective_note": "Drafted 2026-09-19 from CNAB240 version 11.0, which Febraban marks preliminary (5.2). The date is that edition's date; the fields and codes cited are older, and when each first appeared was not traced.", "source_edition": "Layout Padrão Febraban 240 posições, version 11.0 of 2026-09-11, marked preliminary; PDF of 260 pages, relevant sections read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.febraban-cnab240-v11-0", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the payer's claim passes from receiving bank to beneficiary bank to beneficiary, who decides, 3.2.1." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "boleto:exc.payer-claim", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "boleto:rule.pix-qr-on-boleto", "id": "rule.pix-qr-on-boleto", "rail": "boleto", "class": "Rule", "name": "A Pix QR code on a boleto", "statement": "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).", "rests_on": "guidance", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "boleto:src.febraban-cnab240-v11-0", "section": "C010 (pp. 172 to 173); segment Y-04 (p. 74); C047 lists A and C (pp. 181 to 182)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.issuing-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "CNAB240 v11.0 C010, segment Y-04 and C047, read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-11", "effective_to": null, "effective_note": "Drafted 2026-09-19 from CNAB240 version 11.0, which Febraban marks preliminary (5.2). The date is that edition's date; the fields and codes cited are older, and when each first appeared was not traced.", "source_edition": "Layout Padrão Febraban 240 posições, version 11.0 of 2026-09-11, marked preliminary; PDF of 260 pages, relevant sections read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.febraban-cnab240-v11-0", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the distribution codes for a Pix QR coded boleto and the C047 list A rejection codes P1 to P9 and list C code for Pix settlement, C010 and C047." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:rule.proposta-disclosures", "id": "rule.proposta-disclosures", "rail": "boleto", "class": "Rule", "name": "What a proposal boleto must make plain", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 9, I to III", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.issuing-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.beneficiary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "boleto:txn.proposta", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 art. 9, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 from Res. BCB 443, consolidated version 3.0. The date is the day the resolution entered into force (art. 26).", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the disclosure duties for a boleto de proposta, art. 9, I to III." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:rule.proposta-payment-is-acceptance", "id": "rule.proposta-payment-is-acceptance", "rail": "boleto", "class": "Rule", "name": "Paying a proposal boleto accepts the offer", "statement": "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].", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 4, II; art. 9, IV", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.payer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.beneficiary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "boleto:txn.proposta", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 arts. 4 and 9, read 2026-09-19. The consequence for refunds is [Inference].", "confidence": "medium" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 from Res. BCB 443, consolidated version 3.0. The date is the day the resolution entered into force (art. 26).", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms paying a boleto de proposta accepts the offer and the due date is the acceptance deadline, art. 4, II and art. 9, IV." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:rule.proposta-prior-wish", "id": "rule.proposta-prior-wish", "rail": "boleto", "class": "Rule", "name": "A proposal boleto only after the payer asks for it", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 8; art. 22 sole paragraph", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.issuing-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.beneficiary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "boleto:txn.proposta", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 arts. 8 and 22, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 from Res. BCB 443, consolidated version 3.0. The date is the day the resolution entered into force (art. 26).", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms a boleto de proposta needs the payer's prior wish and the issuer's contract duty to require it, art. 8 and art. 22 sole paragraph." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:rule.receiving-liable-for-data-reproduction", "id": "rule.receiving-liable-for-data-reproduction", "rail": "boleto", "class": "Rule", "name": "The receiving institution answers for the data it passes on and for late transfers", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "boleto:src.convencao-cobranca-2021", "section": "arts. 27 §3, 29 sole paragraph, 30 and 33 §2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.receiving-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "2021 convention arts. 27, 29, 30 and 33, read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2021-02-10", "effective_to": null, "effective_note": "Drafted 2026-09-19 from the 2021 convention. The 2021 convention entered into force on 2021-02-10 (art. 36) and was made under Circular 3.598/2012, which Res. BCB 443 revoked; Res. 443 art. 20 §4 required changes to the convention to be submitted to the BCB, and whether a later edition replaces the 2021 text was not established [Unverified].", "source_edition": "Convenção entre instituições participantes do SFN sobre a emissão, apresentação, processamento e liquidação interbancária dos boletos de pagamento, FB-0061/2021, signed 2021-02-05, in force from 2021-02-10; PDF of 39 pages read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.convencao-cobranca-2021", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the receiving institution's exact-reproduction duty, its liability for missed deadlines, and the five-year claim window, arts. 27 par. 3, 29, 30 and 33 par. 2." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:rule.rights-and-duties-sources", "id": "rule.rights-and-duties-sources", "rail": "boleto", "class": "Rule", "name": "Three relationships carry the rights and duties over a boleto", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 22 and sole paragraph", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.issuing-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.receiving-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.destination-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.beneficiary", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 art. 22, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 from Res. BCB 443, consolidated version 3.0. The date is the day the resolution entered into force (art. 26). Merged 2026-09-20: boleto:rule.beneficiary-credit-contractual stated when the beneficiary is credited from the same article of the same resolution, Res. BCB 443 art. 22, and was deleted; the boleto settlement fact that listed it now lists this record. This record was kept because it states all three relationships art. 22 sends rights and duties to, including the issuer to beneficiary contract that decides when the beneficiary is credited, and because its citation covers the sole paragraph as well as the article. The deleted record's binds link to the beneficiary role moved here.", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the three relationships and what governs each: regulation-convention-system rules, issuer-beneficiary contract, and issuer-enabler contract, art. 22." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:rule.siloc-file-exchange", "id": "rule.siloc-file-exchange", "rail": "boleto", "class": "Rule", "name": "SILOC runs on file exchange under Núclea's manuals", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "boleto:src.nuclea-siloc-regulamento", "section": "art. 1, the definition of correlated documents; art. 2 and its sole paragraph; art. 9, the boleto processing stage; art. 13", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "boleto:src.nuclea-siloc-manual-leiautes", "section": "sections 1, 5, 9, 10 and 11", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "boleto:src.nuclea-siloc", "section": "FAQ", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "boleto:src.convencao-cobranca-2021", "section": "art. 2 §§1 and 2; art. 72", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.nuclea", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.receiving-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.destination-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Núclea SILOC operating rulebook, edition 02.01.2026, arts. 1, 2, 9 and 13, and the SILOC layouts manual version 9.0, both read 2026-09-20; Núclea SILOC page FAQ and 2021 convention arts. 2 and 72, read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2026-01-02", "effective_to": null, "effective_note": "Redrafted 2026-09-20 from Núclea's SILOC operating rulebook, version 4.0 of 2026-01-02, and its layouts manual version 9.0, which states its own validity from 2026-02-27 to 2028-02-27. The 2021 convention entered into force on 2021-02-10 (art. 36) and was made under Circular 3.598/2012, which Res. BCB 443 revoked; Res. 443 art. 20 §4 required changes to the convention to be submitted to the BCB, and whether a later edition replaces the 2021 text was not established [Unverified].", "source_edition": "Regulamento Operacional do SILOC, version 4.0, dated 02.01.2026, read 2026-09-20; Manual de Leiautes do SILOC, MAPX-OP082-2019, version 9.0 of 2026-02-27, read 2026-09-20; Núclea SILOC product page, live page with a footer dated 2025, read 2026-09-19; Convenção entre instituições participantes do SFN sobre a emissão, apresentação, processamento e liquidação interbancária dos boletos de pagamento, FB-0061/2021, signed 2021-02-05, in force from 2021-02-10; PDF of 39 pages read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.nuclea-siloc-regulamento", "checked_on": "2026-09-20", "checked_by": "validator-boleto-2026-09-20", "notes": "Confirms the rulebook makes its correlated documents, including the boleto clearing module layouts manual and the card settlement service layouts manual, part of itself and prevailing where the regulation and those documents disagree, and describes the boleto processing stage as receiving institutions sending write-offs and destination institutions sending back returns of those write-offs." }, { "source": "boleto:src.nuclea-siloc-manual-leiautes", "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, sent to a file server on the national financial system network, and the GEN0015 message reporting a participant's multilateral result and bilateral composition, whose fields carry both a clearing house timestamp and a movement date; no boleto transaction layout is in this manual." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:rule.siloc-finality-at-transfer", "id": "rule.siloc-finality-at-transfer", "rail": "boleto", "class": "Rule", "name": "SILOC settlement is final when Núclea's STR account pays out", "statement": "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.", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "boleto:src.nuclea-siloc-regulamento", "section": "art. 1, the definition of the settlement moment; art. 9, item 4(b) of the boleto cycle", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "boleto:src.nuclea-pfmi-report-v4", "section": "principle 8, KC 1 (p. 17); principle 3, KC 2 (p. 15); principle 13, KC 1 (p. 19)", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.nuclea", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Núclea SILOC operating rulebook, edition 02.01.2026, arts. 1 and 9, read 2026-09-20; Núclea PFMI report v4, principles 3, 8 and 13, read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2026-01-02", "effective_to": null, "effective_note": "Redrafted 2026-09-20 to put Núclea's SILOC operating rulebook, version 4.0 of 2026-01-02, beside its PFMI disclosure. The date is that version's; when this finality point was first adopted is not stated, and Res. BCB 304/2023, which Núclea cites for it, was not read [Unverified].", "source_edition": "Regulamento Operacional do SILOC, version 4.0, dated 02.01.2026, read 2026-09-20; Núclea, Relatório Divulgação PFMI CPSS-IOSCO, version 4 (2026 self-assessment, valid to 2028-07-10), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:rule.siloc-net-central-bank-money", "id": "rule.siloc-net-central-bank-money", "rail": "boleto", "class": "Rule", "name": "SILOC nets multilaterally and settles in central bank money", "statement": "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.", "rests_on": "guidance", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "boleto:src.nuclea-siloc", "section": "O que é o SILOC; Como funciona o processo; FAQ", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "boleto:src.nuclea-pfmi-report-v4", "section": "section 4, a.2 (p. 4); principle 9, KC 1 (p. 18)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.nuclea", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Núclea SILOC page and PFMI report v4, read 2026-09-19. Operator publications, not the SILOC rules.", "confidence": "medium" }, "currency": { "effective_since": "2004", "effective_to": null, "effective_note": "Drafted 2026-09-19. The SILOC page says the system has run since 2004; the precise start date and when boletos joined it were not read [Unverified].", "source_edition": "Núclea SILOC product page, live page with a footer dated 2025, read 2026-09-19; Núclea, Relatório Divulgação PFMI CPSS-IOSCO, version 4 (2026 self-assessment, valid to 2028-07-10), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.nuclea-siloc", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms SILOC has run since 2004 and clears boletos, card and ATM items by consolidating files and settling only the net position." }, { "source": "boleto:src.nuclea-pfmi-report-v4", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms SILOC settles interbank obligations in central bank money through settlement accounts at the BCB and the STR, section 4." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:rule.siloc-settlement-default", "id": "rule.siloc-settlement-default", "rail": "boleto", "class": "Rule", "name": "A participant that does not fund its SILOC position is dropped from that cycle", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "boleto:src.nuclea-siloc-regulamento", "section": "arts. 12, 17 and 18; art. 32 and its §§1 and 2; art. 33", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.nuclea", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.bcb", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Núclea SILOC operating rulebook, edition 02.01.2026, arts. 12, 17, 18, 32 and 33, read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2026-01-02", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Núclea's SILOC operating rulebook, which art. 45 puts in force on publication and whose version control table dates version 4.0 to 2026-01-02. The recalculation fee the defaulter owes is set outside the rulebook, in Núclea's SILOC fee communication, which was not read. The 15 minute windows are not held in parameters: the schema's time_window counts banking, calendar or business days and hours, and has no minute unit. The rulebook labels its default chapter as section V while arts. 18, 24 and 32 cross-refer to it as section IV of the same chapter; the numbering is inconsistent in the document itself [Unverified].", "source_edition": "Regulamento Operacional do SILOC, version 4.0, dated 02.01.2026; PDF of 22 pages read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.nuclea-siloc-regulamento", "checked_on": "2026-09-20", "checked_by": "validator-boleto-2026-09-20", "notes": "Confirms a participant that fails to fund its net debit position in full and on time is dropped from the cycle while Núclea reports it to the BCB and the other participants, the multilateral positions are recalculated without it, the remaining participants get 15 minutes after the ordinary deadline to cover the recalculated positions with the deposit and transfer windows extended by a further 15 minutes on each repeat failure with the BCB's agreement, a short or excess deposit is returned at the credit transfer step, the fine schedule runs from a warning letter through the tenth-of-fee-or-fixed-amount penalties counted over 12 months, the defaulting participant owes the recalculation cost, and an appeal to Núclea's board within 7 business days suspends the penalty." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:rule.siloc-settlement-timing", "id": "rule.siloc-settlement-timing", "rail": "boleto", "class": "Rule", "name": "SILOC settles boletos in two cycles: 16:10 the same business day, 08:20 the next", "statement": "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.", "rests_on": "rule", "facet": "settlement", "parameters": { "time_window": { "times": [ "08:20", "16:10" ], "timezone": "America/Sao_Paulo", "on": "business_day", "text": "net credits reach participants at 08:20 in the first cycle and 16:10 in the second; the rulebook states no time zone, and the STR runs on Brasília time [Inference]" } }, "relations": [ { "type": "sourced_from", "to": "boleto:src.nuclea-siloc-regulamento", "section": "art. 14, the boleto funds transfer stage table; arts. 8, 9, 13 and 38 on the stages and where their routines and deadlines sit", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "boleto:src.nuclea-siloc-manual-operacoes", "section": "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)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "boleto:src.nuclea-siloc", "section": "Formas de Liquidação", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "boleto:src.nuclea-pfmi-report-v4", "section": "principle 8, KC 2 (p. 17)", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.nuclea", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Núclea SILOC operating rulebook, edition 02.01.2026, arts. 8, 9, 13, 14 and 38, 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; Núclea SILOC page and PFMI report v4, read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2026-01-02", "effective_to": null, "effective_note": "Redrafted 2026-09-20 from Núclea's SILOC operating rulebook, which art. 45 puts in force on publication and whose version control table dates version 4.0 to 2026-01-02. That version records the removal of Tecban and adjustments to the clearing process, so the cycle times may have moved with it and earlier times were not compared [Unverified]. Redrafted again 2026-09-22 from the SILOC manual of operations, version 31.0, in force from 2026-01-12, which settles the day each cycle falls on (conflict boleto-siloc-settlement-day).", "source_edition": "Regulamento Operacional do SILOC, version 4.0, dated 02.01.2026, read 2026-09-20; Núclea SILOC product page, live page with a footer dated 2025, read 2026-09-19; Núclea, Relatório Divulgação PFMI CPSS-IOSCO, version 4 (2026 self-assessment, valid to 2028-07-10), read 2026-09-19; Manual de Operações do SILOC MAPX-OP002-2004, version 31.0, in force 2026-01-12 to 2028-01-12, read 2026-09-22", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.nuclea-siloc-regulamento", "checked_on": "2026-09-20", "checked_by": "validator-boleto-2026-09-20", "notes": "Confirms the SILOC boleto funds transfer stage runs two cycles a business day, with the debtor-position deposit request at 07:00 and 15:20, a deposit window closing at 08:00 and 15:50, and the net credit transfer to participants at 08:20 and 16:10, and that the rulebook sets no clock for the processing and clearing stages, leaving those routines to the SILOC manual of operations." }, { "source": "boleto:src.nuclea-siloc-manual-operacoes", "checked_on": "2026-09-23", "checked_by": "validator-opus-2026-09-23", "notes": "Confirms from version 31.0 (SHA-256 8f94b521...2f01d) sections 11.1 and 11.1.1 that the boleto cycle runs twice a business day; that the afternoon cycle, with its last partial clearing result at 15:00, final result by 15:05, deposit window 15:20 to 15:50 and credit transfer at 16:10, falls on the date of processing; that the morning cycle, with its partial result by 01:00 or 02:00 after a national holiday, final result by 05:10, deposit window 07:00 to 08:00 and credit transfer at 08:20, falls on the next business day; and that the detail of the clearing stage is left to the SILOC processing manual." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:rule.str-60-minute-send", "id": "rule.str-60-minute-send", "rail": "boleto", "class": "Rule", "name": "STR boleto transfers go to settlement within 60 minutes of payment", "statement": "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.", "rests_on": "rule", "facet": "hours", "parameters": { "time_window": { "count": 1, "unit": "hour", "from": "receipt", "text": "within 60 minutes of the payer's payment" } }, "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 16 §1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "boleto:src.convencao-cobranca-2021", "section": "art. 27 §1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.receiving-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "boleto:txn.cobranca-comum", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "boleto:txn.proposta", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "boleto:txn.deposito-e-aporte", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 art. 16 §1; 2021 convention art. 27 §1; read 2026-09-19. The time_window counts from receipt, meaning the receiving institution's receipt of the payer's payment.", "confidence": "high" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 from Res. BCB 443, consolidated version 3.0. The date is the day the resolution entered into force (art. 26). The lines from the 2021 convention carry its own doubt: The 2021 convention entered into force on 2021-02-10 (art. 36) and was made under Circular 3.598/2012, which Res. BCB 443 revoked; Res. 443 art. 20 §4 required changes to the convention to be submitted to the BCB, and whether a later edition replaces the 2021 text was not established [Unverified].", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19; Convenção entre instituições participantes do SFN sobre a emissão, apresentação, processamento e liquidação interbancária dos boletos de pagamento, FB-0061/2021, signed 2021-02-05, in force from 2021-02-10; PDF of 39 pages read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms an STR credit transfer must settle within sixty minutes of the payer's payment, art. 16 par. 1." }, { "source": "boleto:src.convencao-cobranca-2021", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the same one-hour STR limit, bounded by the STR day's close, art. 27 par. 1." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:rule.str-hold-for-irregularity", "id": "rule.str-hold-for-irregularity", "rail": "boleto", "class": "Rule", "name": "The receiving institution may hold an STR transfer to check for irregularity", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 16 §2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.receiving-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "boleto:txn.cobranca-comum", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "boleto:txn.proposta", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "boleto:txn.deposito-e-aporte", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 art. 16 §2, read 2026-09-19. Decision-points readings are capped at medium.", "confidence": "medium" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 from Res. BCB 443, consolidated version 3.0. The date is the day the resolution entered into force (art. 26).", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the receiving institution may hold an STR transfer beyond 60 minutes only as long as strictly needed to investigate irregularity, art. 16 par. 2." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:rule.str-route-large-boletos", "id": "rule.str-route-large-boletos", "rail": "boleto", "class": "Rule", "name": "Boletos at or above the VR-Boleto settle gross over STR the same day", "statement": "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].", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 16, I; art. 19", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.receiving-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "boleto:txn.cobranca-comum", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "boleto:txn.proposta", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "boleto:txn.deposito-e-aporte", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 art. 16, I and art. 19, read in Portuguese 2026-09-19 and stated in Orca's own words. The message code is not in the resolution.", "confidence": "high" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 from Res. BCB 443, consolidated version 3.0. The date is the day the resolution entered into force (art. 26).", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms a boleto at or above the VR-Boleto settles gross over STR the same day, via a specific SFN service catalog message not named in the resolution, art. 16, I and art. 19." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:rule.str-transfers-by-noon", "id": "rule.str-transfers-by-noon", "rail": "boleto", "class": "Rule", "name": "STR devoluções and adjustments by 12:00", "statement": "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.", "rests_on": "rule", "facet": "hours", "parameters": { "time_window": { "times": [ "12:00" ], "timezone": "America/Sao_Paulo", "on": "business_day", "text": "by 12:00, Brasília time assumed" } }, "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 18 §2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "boleto:src.convencao-cobranca-2021", "section": "art. 31, I", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.destination-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "boleto:exc.interbank-devolucao", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "boleto:rule.devolucao-same-system", "note": "The rule that sends a devolucao down the STR route this record sets the deadline for. That record is art. 18, which system must be used; this one is art. 18 paragraph 2 and the 2021 convention, the noon cut-off.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 art. 18 §2; 2021 convention art. 31, I; read 2026-09-19. The time zone and the day (the business day after settlement) are not in Res. 443.", "confidence": "medium" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 from Res. BCB 443, consolidated version 3.0. The date is the day the resolution entered into force (art. 26). The lines from the 2021 convention carry its own doubt: The 2021 convention entered into force on 2021-02-10 (art. 36) and was made under Circular 3.598/2012, which Res. BCB 443 revoked; Res. 443 art. 20 §4 required changes to the convention to be submitted to the BCB, and whether a later edition replaces the 2021 text was not established [Unverified].", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19; Convenção entre instituições participantes do SFN sobre a emissão, apresentação, processamento e liquidação interbancária dos boletos de pagamento, FB-0061/2021, signed 2021-02-05, in force from 2021-02-10; PDF of 39 pages read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms an STR devolucao or acerto de diferenca must go by 12:00, art. 18 par. 2." }, { "source": "boleto:src.convencao-cobranca-2021", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the 12:00 deadline on the business day after settlement for STR devolucoes on automatable grounds, art. 31, I." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "boleto:exc.interbank-devolucao", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.devolucao-same-system", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "boleto:rule.vr-boleto-threshold", "id": "rule.vr-boleto-threshold", "rail": "boleto", "class": "Rule", "name": "VR-Boleto: the R$250,000.00 routing threshold", "statement": "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].", "rests_on": "rule", "facet": "limits", "parameters": { "limit": { "amount": 250000, "currency": "BRL", "per": "entry", "text": "R$250,000.00 per boleto, a settlement routing threshold, not a cap" } }, "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 19; art. 16, I and II; art. 17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "applies_to", "to": "boleto:txn.cobranca-comum", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "boleto:txn.proposta", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "boleto:txn.deposito-e-aporte", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 arts. 16, 17 and 19, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 from Res. BCB 443, consolidated version 3.0. The date is the day the resolution entered into force (art. 26).", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the VR-Boleto is fixed at R250,000.00 and decides the settlement route rather than capping the amount, art. 16, I and II, art. 17 and art. 19." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:rule.write-off", "id": "rule.write-off", "rail": "boleto", "class": "Rule", "name": "Write-off (baixa) of an unpaid title", "statement": "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.", "rests_on": "guidance", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "boleto:src.febraban-cnab240-v11-0", "section": "segment P fields 38 and 39 (p. 69); C028 and C029 (pp. 175 to 176); C044 (p. 177); C047 list C (p. 182)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.beneficiary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "boleto:role.issuing-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "CNAB240 v11.0 segment P, C028, C029, C044 and C047, read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-11", "effective_to": null, "effective_note": "Drafted 2026-09-19 from CNAB240 version 11.0, which Febraban marks preliminary (5.2). The date is that edition's date; the fields and codes cited are older, and when each first appeared was not traced.", "source_edition": "Layout Padrão Febraban 240 posições, version 11.0 of 2026-09-11, marked preliminary; PDF of 260 pages, relevant sections read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.febraban-cnab240-v11-0", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms movement code 09 for baixa, segment P fields 38 and 39 (C028, C029) for the write-off-on-lapse setting, and the related C047 list C reasons." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "boleto:src.bcb-instrucao-normativa-611", "id": "src.bcb-instrucao-normativa-611", "rail": "boleto", "class": "RuleSource", "name": "Instrução Normativa BCB nº 611, assets eligible for dynamic boletos", "summary": "Lists the two financial asset types that may be linked to a dynamic cobrança boleto and says how the rollout schedule for each asset is agreed and sent to the BCB. In Portuguese.", "publisher": "Banco Central do Brasil", "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", "kind": "regulation", "edition": "Instrução Normativa BCB nº 611 of 2025-04-22, version 1.0, in force 2025-04-30, read with its supporting Nota 238/2025 on 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The instruction and its supporting Nota 238/2025, read in full from the BCB normativos data endpoint on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-19 for the boleto rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "Instrução Normativa BCB nº 611 of 2025-04-22, version 1.0, in force 2025-04-30, read with its supporting Nota 238/2025 on 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "boleto:role.bcb", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.dynamic-asset-links", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:txn.cobranca-dinamico", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "boleto:src.bcb-resolucao-443", "id": "src.bcb-resolucao-443", "rail": "boleto", "class": "RuleSource", "name": "Resolução BCB nº 443, arranjo de pagamento do boleto (consolidated)", "summary": "The BCB's regulation of the boleto payment arrangement: the three species and the two cobrança modalities, roles, participation, minimum content and presentment, dynamic boletos, third-party enablers, the settlement routes and the VR-Boleto, devolução and acerto de diferença, and the participants' convention and its governance. In Portuguese.", "publisher": "Banco Central do Brasil", "url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20BCB&numero=443", "source_class": "authoritative_primary", "kind": "regulation", "edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The consolidated text, read in full from the BCB normativos data endpoint (https://www.bcb.gov.br/api/conteudo/app/normativos/exibenormativo?p1=Resolu%C3%A7%C3%A3o%20BCB&p2=443), which serves the text behind the script-rendered page at the URL given; VersaoNormativo 3.0 and the Atualizacoes list were read with it.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-19 for the boleto rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "boleto:rail.boleto", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "boleto:exc.interbank-devolucao", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:role.bcb", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:role.beneficiary", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:role.convention-governance", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:role.destination-institution", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:role.issuing-institution", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:role.nuclea", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:role.payer", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:role.receiving-institution", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:role.rights-holder", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:role.third-party-enabler", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.boleto-paid-through-other-arrangement", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.central-database-registration", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.convention-delegation", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.convention-governance", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.devolucao-next-business-day", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.devolucao-same-system", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.direct-or-represented-settlement", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.dynamic-always-nets", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.dynamic-asset-links", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.electronic-presentment-consent", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.enabler-due-diligence", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.issuer-must-issue-dynamic", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.issuer-risk-management", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.minimum-content", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.netting-route-below-threshold", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.participation-eligibility", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.proposta-disclosures", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.proposta-payment-is-acceptance", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.proposta-prior-wish", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.rights-and-duties-sources", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.str-60-minute-send", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.str-hold-for-irregularity", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.str-route-large-boletos", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.str-transfers-by-noon", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.vr-boleto-threshold", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:txn.cobranca-comum", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:txn.cobranca-dinamico", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:txn.deposito-e-aporte", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:txn.proposta", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "boleto:src.cip-dda-termo-adesao", "id": "src.cip-dda-termo-adesao", "rail": "boleto", "class": "RuleSource", "name": "Termo de Adesão ao Sistema de Débito Direto Autorizado, DDA, CIP", "summary": "The membership terms a bank signs to join DDA, Brazil's authorised direct debit system, run by CIP, now Núclea. It defines DDA as an electronic system for presenting and looking up boletos, a repository of collection data built by the participating institutions sending and obtaining data; it requires a joining bank to be a SILOC participant already; and it names the DDA convention, the appeal college rules and the DDA Manual de Operações as the documents that govern the system, none of which it reproduces. The rest is contractual: homologation of the bank's systems, fees, penalties, term and forum.", "publisher": "Câmara Interbancária de Pagamentos (CIP), now Núclea", "url": "https://www2.nuclea.com.br/Juridico/Termo%20de%20Ades%C3%A3o%20ao%20Sistema%20de%20D%C3%A9bito%20Direto%20Autorizado%20-%20DDA.pdf", "source_class": "authoritative_primary", "kind": "membership_terms", "edition": "signed São Paulo 2017-10-02, registered with the 10th register of titles and documents of the capital on 2017-10-09, listed on Núclea's documents page as dated 2018-10-07; scanned PDF of 4 pages with no text layer, read as page images, 1,774,905 bytes, SHA-256 84033b4626a5f58c2c95bb5692b2ce610ab1bdfb95f1c4e36787f154cd038243", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, read in full on 2026-09-20: the recitals and clauses one to seven. The PDF holds only scanned page images, so the pages were read as images rather than extracted as text.", "confidence": "medium" }, "currency": { "effective_since": "2017-10-02", "effective_to": null, "effective_note": "Created 2026-09-20 for the boleto rail. The date is the day the document was signed. It is nine years old and CIP has since renamed itself Núclea, so whether Núclea still issues these terms unchanged was not established [Unverified]. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "signed São Paulo 2017-10-02, registered with the 10th register of titles and documents of the capital on 2017-10-09, listed on Núclea's documents page as dated 2018-10-07; scanned PDF of 4 pages with no text layer, read as page images, 1,774,905 bytes, SHA-256 84033b4626a5f58c2c95bb5692b2ce610ab1bdfb95f1c4e36787f154cd038243", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "boleto:rule.electronic-presentment-consent", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "boleto:src.convencao-cobranca-2021", "id": "src.convencao-cobranca-2021", "rail": "boleto", "class": "RuleSource", "name": "Convenção da Cobrança, FB-0061/2021 (boleto convention of 5 February 2021)", "summary": "The participants' convention on issuing, presenting, processing and settling boletos between institutions, signed by ABBC, ABBI, ABECS and Febraban with CIP (now Núclea) as processor. It sets the central database, registration, receipt and contingency rules, the settlement routes, the devolução grounds and deadlines (annexes VI and VII), liability between institutions, a mediation committee and penalties. It was made under Circular 3.598/2012, which Res. BCB 443 revoked, and it is the only edition of the convention found in public. In Portuguese.", "publisher": "Febraban, for the signatory associations", "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", "kind": "convention", "edition": "FB-0061/2021, signed 2021-02-05, in force from 2021-02-10; PDF of 39 pages, 7,149,557 bytes, SHA-256 da66c4e37ed636276549bcee8db0d50f10ecf334affb83bf88dd61d955def1c3", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, linked from Febraban's Nova Plataforma de Boletos page, downloaded and read on 2026-09-19 (text extracted with pypdf): articles 1 to 38, 69 to 78 and annexes I, VI and VII. Whether it is still the edition in force under Res. BCB 443 art. 20 is [Unverified].", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-19 for the boleto rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "FB-0061/2021, signed 2021-02-05, in force from 2021-02-10; PDF of 39 pages, 7,149,557 bytes, SHA-256 da66c4e37ed636276549bcee8db0d50f10ecf334affb83bf88dd61d955def1c3", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "boleto:exc.interbank-devolucao", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:role.convention-governance", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:role.nuclea", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:role.receiving-institution", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.barcode-standard", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.cash-payment-ceiling", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.central-database-registration", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.convention-delegation", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.destination-liable-for-slip-errors", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.devolucao-convention-grounds", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.entry-rejection", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.interbank-receipt-data-informative", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.netting-route-below-threshold", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.non-business-day-due-date", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.nonconforming-payment-reversal-attempt", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.receiving-liable-for-data-reproduction", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.siloc-file-exchange", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.str-60-minute-send", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.str-transfers-by-noon", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:txn.deposito-e-aporte", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "boleto:src.febraban-cnab240-v11-0", "id": "src.febraban-cnab240-v11-0", "rail": "boleto", "class": "RuleSource", "name": "Layout Padrão Febraban 240 posições (CNAB240), version 11.0", "summary": "Febraban's standard for files exchanged between companies and banks. Section 3.2 (Cobrança) covers registering titles, instructions, the bank's return file, electronic boleto presentment and payer claims, with field descriptions C001 onward. It is a bank-to-client standard, offered by each bank under its own agreement; it does not govern interbank settlement. In Portuguese.", "publisher": "Febraban", "url": "https://cmsarquivos.febraban.org.br/Arquivos/documentos/PDF/Layout%20padrao%20CNAB240%20V%2011_0%20-%202026_09_11.pdf", "source_class": "public_primary", "kind": "file_standard", "edition": "version 11.0 of 2026-09-11, marked preliminary with a revision promised within three weeks (5.2); PDF of 260 pages, 6,580,300 bytes, SHA-256 95a67618027784e9b9b4c4a48c8290082c2bb2245db758619a733f80f36204f4", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, read on 2026-09-19 (text extracted with pypdf): 1.1 and 1.0 (pp. 6 to 8), 3.2.1 (pp. 64 to 67), segment P (p. 69), segment Y-04 (p. 74), field descriptions C010, C028, C029, C044 and C047 (pp. 172 to 183), G063 and G065 (p. 208), and 5.2 (pp. 252 to 253).", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-19 for the boleto rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "version 11.0 of 2026-09-11, marked preliminary with a revision promised within three weeks (5.2); PDF of 260 pages, 6,580,300 bytes, SHA-256 95a67618027784e9b9b4c4a48c8290082c2bb2245db758619a733f80f36204f4", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "boleto:exc.entry-rejection", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:exc.payer-claim", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:role.beneficiary", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.barcode-standard", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.boleto-paid-through-other-arrangement", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.company-bank-file-standard", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.entry-rejection", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.partial-payment-settings", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.payer-claim", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.pix-qr-on-boleto", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.write-off", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "boleto:src.febraban-nova-plataforma-boletos", "id": "src.febraban-nova-plataforma-boletos", "rail": "boleto", "class": "RuleSource", "name": "Nova Plataforma de Boletos de Pagamento, Cobrança Registrada", "summary": "Febraban's page on the industry programme that moved boletos into a registered model checked against a central database: where the boleto came from, when the platform started and when it was complete, with a link to the 2021 convention.", "publisher": "Febraban", "url": "https://portal.febraban.org.br/pagina/3150/1094/pt-br/servicos-novo-plataforma-boletos", "source_class": "public_primary", "kind": "web_page", "edition": "Febraban page Nova Plataforma de Boletos de Pagamento, Cobrança Registrada, undated live page read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The page itself, read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-19 for the boleto rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "Febraban page Nova Plataforma de Boletos de Pagamento, Cobrança Registrada, undated live page read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "boleto:rule.convention-delegation", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "boleto:src.nuclea-pfmi-report-v4", "id": "src.nuclea-pfmi-report-v4", "rail": "boleto", "class": "RuleSource", "name": "Relatório Divulgação PFMI CPSS-IOSCO, Núclea, version 4", "summary": "Núclea's public self-assessment against the CPMI-IOSCO Principles for Financial Market Infrastructures for SITRAF, SILOC and the C3 registry: its services, including SILOC and the central boleto database (PCR), settlement finality, money settlement, default handling and access.", "publisher": "Núclea (CIP S.A.)", "url": "https://www2.nuclea.com.br/Compliance/Relat%C3%B3rio%20N%C3%BAclea_%20PFMI%20CPSS-IOSCO.pdf", "source_class": "public_primary", "kind": "disclosure_report", "edition": "version 4, 2026 self-assessment, valid to 2028-07-10, marked public; PDF of 38 pages, 1,353,526 bytes, SHA-256 d6cf927576b0dd9d2431f4cf13de67fc79f8106b77606d92a925e6f66d23c0d5", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, read on 2026-09-19 (text extracted with pypdf): sections 1 to 4 and principles 3, 8, 9, 13 and 18.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-19 for the boleto rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "version 4, 2026 self-assessment, valid to 2028-07-10, marked public; PDF of 38 pages, 1,353,526 bytes, SHA-256 d6cf927576b0dd9d2431f4cf13de67fc79f8106b77606d92a925e6f66d23c0d5", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "boleto:rail.boleto", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "boleto:role.bcb", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "boleto:role.nuclea", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.central-database-registration", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.siloc-finality-at-transfer", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.siloc-net-central-bank-money", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.siloc-settlement-timing", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "boleto:src.nuclea-siloc-manual-leiautes", "id": "src.nuclea-siloc-manual-leiautes", "rail": "boleto", "class": "RuleSource", "name": "Manual de Leiautes do SILOC, MAPX-OP082-2019, Núclea", "summary": "Núclea's public layouts manual for SILOC, covering two artefacts only: the participant relation file, a fixed-width file listing each participant's ISPB, bank code and per-product activation and expiry dates, published over FTP on the national financial system network; and the GEN0015 message, which carries a participant's multilateral result and its bilateral composition after each cycle. It marks itself public, names the SILOC Manual de Operações and Manual Técnico as its complements, and covers no boleto transaction layout.", "publisher": "Núclea (CIP S.A.)", "url": "https://www2.nuclea.com.br/Compliance/MAPX-OP082-2019%20-%20Manual%20de%20Leiautes%20do%20SILOC.pdf", "source_class": "authoritative_primary", "kind": "layouts_manual", "edition": "version 9.0, published 2026-02-27, stated valid from 2026-02-27 to 2028-02-27, marked a public corporate document; PDF of 9 pages, 432,307 bytes, SHA-256 8ab320f54af9522740e47a7a0967492c49c877aa560726581a54c7361a69a760", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, read in full on 2026-09-20 (text extracted with pypdf): sections 1 to 14.", "confidence": "high" }, "currency": { "effective_since": "2026-02-27", "effective_to": "2028-02-27", "effective_note": "Created 2026-09-20 for the boleto rail. The manual states its own validity period on every page. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "version 9.0, published 2026-02-27, stated valid from 2026-02-27 to 2028-02-27, marked a public corporate document; PDF of 9 pages, 432,307 bytes, SHA-256 8ab320f54af9522740e47a7a0967492c49c877aa560726581a54c7361a69a760", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "boleto:rule.siloc-file-exchange", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "boleto:src.nuclea-siloc-manual-operacoes", "id": "src.nuclea-siloc-manual-operacoes", "rail": "boleto", "class": "RuleSource", "name": "Manual de Operações do SILOC (MAPX-OP002-2004), Núclea", "summary": "Núclea's manual of operations for SILOC, marked by Núclea as a public corporate document: the products SILOC settles, participant status and admission, operational risks, and the operating cycles, with the clock times of the processing, clearing and funds transfer stages of the two boleto cycles and the day each cycle falls on, then the card cycles, the operational message flows and the cost recovery charges. It leaves the detail of the clearing stage to a separate SILOC processing manual.", "publisher": "Núclea (CIP S.A.)", "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", "kind": "operations_manual", "edition": "version 31.0, in force 12/01/2026 to 12/01/2028 by its page header; PDF of 53 pages, 1,550,999 bytes, SHA-256 8f94b5213f6034a5bad4b274a8051612776a76c538fe5ec9e84e845e4ad2f01d", "access": "open", "consulted_on": "2026-09-22", "relations": [], "basis": { "sources": "The document itself, opened 2026-09-22 (text taken with the operating system's PDF reader and the timetable pages 24 and 25 read from the rendered page): section 11, operating cycles, and 11.1 and 11.1.1 on the boleto (Cobrança) cycle and its timetable. Other sections were not read in full.", "confidence": "medium" }, "currency": { "effective_since": "2026-01-12", "effective_to": "2028-01-12", "effective_note": "Created 2026-09-22 for the boleto rail. The page header gives version 31.0 and a validity from 12/01/2026 to 12/01/2028. The SILOC operating rulebook (arts. 8, 13 and 38) hands stage routines and deadlines to this manual. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "version 31.0, in force 12/01/2026 to 12/01/2028; PDF of 53 pages, SHA-256 8f94b5213f6034a5bad4b274a8051612776a76c538fe5ec9e84e845e4ad2f01d", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "boleto:rule.siloc-settlement-timing", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "boleto:src.nuclea-siloc-regulamento", "id": "src.nuclea-siloc-regulamento", "rail": "boleto", "class": "RuleSource", "name": "Regulamento Operacional do SILOC, Núclea", "summary": "Núclea's operating rulebook for SILOC, its deferred net settlement system: the defined terms, the settlement cycles and their stages for boleto and card items, the clock times of the funds transfer stage, what happens when a participant fails to fund its debit position, access, suspension and exclusion, emergency powers, penalties and appeals. It names the SILOC Manual de Operações and the other correlated manuals as the place where the routines, deadlines and file layouts sit, and gives itself priority over them where they disagree.", "publisher": "Núclea (CIP S.A.)", "url": "https://www2.nuclea.com.br/ProdutosIMF/Regulamento%20Operacional%20do%20SILOC.pdf", "source_class": "authoritative_primary", "kind": "operating_rulebook", "edition": "version 4.0, dated 02.01.2026 on its cover and signed São Paulo 2026-01-02, listed on Núclea's documents page as dated 2026-03-20; PDF of 22 pages, 433,656 bytes, SHA-256 362cdd1d07e282cab3a7ade65e752d9a5d1400e051fc667e235495352ca556b5", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, read in full on 2026-09-20 (text extracted with pypdf): arts. 1 to 45 and the version control table.", "confidence": "high" }, "currency": { "effective_since": "2026-01-02", "effective_to": null, "effective_note": "Created 2026-09-20 for the boleto rail. Art. 45 puts the rulebook in force on the date of its publication, and the version control table dates version 4.0 to 2026-01-02. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "version 4.0, dated 02.01.2026 on its cover and signed São Paulo 2026-01-02, listed on Núclea's documents page as dated 2026-03-20; PDF of 22 pages, 433,656 bytes, SHA-256 362cdd1d07e282cab3a7ade65e752d9a5d1400e051fc667e235495352ca556b5", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "boleto:rule.central-database-registration", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.siloc-file-exchange", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.siloc-finality-at-transfer", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.siloc-settlement-default", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.siloc-settlement-timing", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "boleto:src.nuclea-siloc", "id": "src.nuclea-siloc", "rail": "boleto", "class": "RuleSource", "name": "Liquidação de Operações de Crédito, SILOC (Núclea product page)", "summary": "Núclea's page for SILOC, its deferred net settlement system for boletos and card items: what it does, its settlement models, how clearing and settlement work, and an FAQ naming its regulation and manuals.", "publisher": "Núclea (CIP S.A.)", "url": "https://www.nuclea.com.br/liquidacao-de-operacoes-de-credito-siloc/", "source_class": "public_primary", "kind": "web_page", "edition": "Núclea SILOC product page, live page with a footer dated 2025, read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The page itself, including its FAQ, read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-19 for the boleto rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "Núclea SILOC product page, live page with a footer dated 2025, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "boleto:role.nuclea", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.direct-or-represented-settlement", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.siloc-file-exchange", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.siloc-net-central-bank-money", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "boleto:rule.siloc-settlement-timing", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "boleto:txn.cobranca-comum", "id": "txn.cobranca-comum", "rail": "boleto", "class": "TransactionType", "name": "Boleto de cobrança, common (comum)", "summary": "A bill for a debt of any kind whose beneficiary and destination institution cannot change: the original creditor is paid through its own issuing bank. It settles over STR the same day at or above the VR-Boleto and by netting or STR below it. Where the BCB allows it for an asset type, it can be converted into a dynamic boleto without a new slip or a new identifier.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 5, I, a, §1-A and §2; art. 16", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 arts. 5 and 16, read 2026-09-19. sec_code is null: the boleto has no entry class codes. directions is credit: the payer pushes the payment.", "confidence": "high" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 from Res. BCB 443, consolidated version 3.0. The date is the day the resolution entered into force (art. 26).", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms boleto de cobranca comum keeps the same destination institution and beneficiary, its STR or netting settlement route, and its optional conversion to dynamic, art. 5 and art. 16." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "boleto:rule.issuer-must-issue-dynamic", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.netting-route-below-threshold", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.str-60-minute-send", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.str-hold-for-irregularity", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.str-route-large-boletos", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.vr-boleto-threshold", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "boleto:txn.cobranca-dinamico", "id": "txn.cobranca-dinamico", "rail": "boleto", "class": "TransactionType", "name": "Boleto de cobrança, dynamic (dinâmico)", "summary": "A bill linked to a financial asset held in a BCB-authorised recording, registry or depository system; today the eligible assets are electronic duplicatas and certain real-estate sale receivables. When the asset is traded, that system instructs a change of beneficiary to the rights holder and possibly of destination institution, and the payer sees the current details in the receiving institution's app or website. It always settles by multilateral netting.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 5, I, b and §1; arts. 10 and 17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "boleto:src.bcb-instrucao-normativa-611", "section": "art. 1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 arts. 5, 10 and 17; IN BCB 611 art. 1; read 2026-09-19. sec_code is null: the boleto has no entry class codes. directions is credit: the payer pushes the payment.", "confidence": "high" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 from Res. BCB 443, consolidated version 3.0. The date is the day the resolution entered into force (art. 26).", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the dynamic boleto's link to a recorded, registered or deposited asset, the beneficiary and destination change on trading, and its exclusive netting settlement, art. 5, art. 10 and art. 17." }, { "source": "boleto:src.bcb-instrucao-normativa-611", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the two eligible asset types today are electronic duplicatas and certain real-estate sale receivables, art. 1." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "boleto:rule.dynamic-always-nets", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.dynamic-asset-links", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.issuer-must-issue-dynamic", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "boleto:txn.deposito-e-aporte", "id": "txn.deposito-e-aporte", "rail": "boleto", "class": "TransactionType", "name": "Boleto de depósito e aporte", "summary": "A slip used to put money into a deposit or prepaid payment account held by the payer: the payer and the beneficiary are the same account holder.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 3, I, c and IV, c; art. 4, III; art. 5, III", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "boleto:src.convencao-cobranca-2021", "section": "art. 9 §4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 arts. 3 to 5; 2021 convention art. 9 §4 (the beneficiary's and payer's tax numbers must match); read 2026-09-19. sec_code is null: the boleto has no entry class codes. directions is credit: the payer pushes the payment.", "confidence": "high" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 from Res. BCB 443, consolidated version 3.0. The date is the day the resolution entered into force (art. 26). The lines from the 2021 convention carry its own doubt: The 2021 convention entered into force on 2021-02-10 (art. 36) and was made under Circular 3.598/2012, which Res. BCB 443 revoked; Res. 443 art. 20 §4 required changes to the convention to be submitted to the BCB, and whether a later edition replaces the 2021 text was not established [Unverified].", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the deposito e aporte boleto funds the payer's own deposit or prepaid account, arts. 3 to 5." }, { "source": "boleto:src.convencao-cobranca-2021", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the beneficiario final's CPF or CNPJ must match the pagador's for a deposito e aporte boleto, art. 9 par. 4." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "boleto:rule.netting-route-below-threshold", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.str-60-minute-send", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.str-hold-for-irregularity", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.str-route-large-boletos", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.vr-boleto-threshold", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "boleto:txn.proposta", "id": "txn.proposta", "rail": "boleto", "class": "TransactionType", "name": "Boleto de proposta", "summary": "A slip carrying an offer of a product or service, a civil contract proposal or a membership invitation, which the payer accepts by paying it. It may go only to someone who first asked to receive it, and must make plain that paying is optional.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "boleto:src.bcb-resolucao-443", "section": "art. 4, II; art. 5, II; arts. 8 and 9", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Res. BCB 443 arts. 4, 5, 8 and 9, read 2026-09-19. sec_code is null: the boleto has no entry class codes. directions is credit: the payer pushes the payment.", "confidence": "high" }, "currency": { "effective_since": "2025-02-03", "effective_to": null, "effective_note": "Drafted 2026-09-19 from Res. BCB 443, consolidated version 3.0. The date is the day the resolution entered into force (art. 26).", "source_edition": "Resolução BCB nº 443 of 2024-12-12, consolidated text version 3.0 (amended by Res. BCB 467/2025 and 515/2025), read in Portuguese from the BCB normativos data endpoint on 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "boleto:src.bcb-resolucao-443", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the boleto de proposta carries an offer or proposal accepted by payment, requires the payer's prior wish, and must disclose that paying is optional, arts. 4, 5, 8 and 9." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "boleto:rule.netting-route-below-threshold", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.proposta-disclosures", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.proposta-payment-is-acceptance", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.proposta-prior-wish", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.str-60-minute-send", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.str-hold-for-irregularity", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.str-route-large-boletos", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.vr-boleto-threshold", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "boleto:rule.electronic-presentment-consent", "boleto:rule.proposta-prior-wish", "boleto:rule.proposta-disclosures", "boleto:rule.proposta-payment-is-acceptance", "boleto:rule.minimum-content" ], "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.", "relations": [ { "type": "see_also", "to": "pix:consumer-law", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "boleto:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "boleto:src.bcb-resolucao-443", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "boleto:refund", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "boleto:rule.str-hold-for-irregularity", "boleto:rule.netting-route-below-threshold", "boleto:rule.issuer-must-issue-dynamic", "boleto:rule.payer-claim", "boleto:rule.convention-governance" ], "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, "relations": [], "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": "boleto:src.bcb-resolucao-443", "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": "boleto:src.febraban-cnab240-v11-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "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.", "rules": [ "boleto:rule.str-route-large-boletos", "boleto:rule.str-60-minute-send", "boleto:rule.netting-route-below-threshold", "boleto:rule.siloc-finality-at-transfer", "boleto:rule.interbank-receipt-data-informative", "boleto:rule.devolucao-same-system", "boleto:rule.boleto-paid-through-other-arrangement" ], "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.", "relations": [ { "type": "see_also", "to": "pix:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "boleto:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "boleto:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "boleto:src.bcb-resolucao-443", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "boleto:settlement", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "boleto:rule.str-60-minute-send", "boleto:rule.str-hold-for-irregularity", "boleto:rule.str-transfers-by-noon", "boleto:rule.devolucao-next-business-day", "boleto:rule.siloc-settlement-timing", "boleto:rule.non-business-day-due-date" ], "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.", "relations": [ { "type": "see_also", "to": "pix:hours", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "boleto:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "boleto:src.nuclea-siloc-regulamento", "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": "boleto:src.nuclea-siloc-manual-operacoes", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "boleto:settlement", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "boleto:rule.rights-and-duties-sources", "boleto:rule.issuer-risk-management", "boleto:rule.enabler-due-diligence", "boleto:rule.destination-liable-for-slip-errors", "boleto:rule.receiving-liable-for-data-reproduction", "boleto:rule.central-database-registration" ], "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.", "relations": [], "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": "boleto:src.bcb-resolucao-443", "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": "boleto:src.convencao-cobranca-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "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.", "rules": [ "boleto:rule.vr-boleto-threshold", "boleto:rule.cash-payment-ceiling", "boleto:rule.partial-payment-settings" ], "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.", "relations": [], "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": "boleto:src.bcb-resolucao-443", "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": "boleto:src.convencao-cobranca-2021", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the R10,000.00 cash ceiling, arts. 18 to 21." }, { "source": "boleto:src.febraban-cnab240-v11-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": "boleto:src.febraban-nova-plataforma-boletos", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "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.", "rules": [ "boleto:rule.minimum-content", "boleto:rule.central-database-registration", "boleto:rule.barcode-standard", "boleto:rule.company-bank-file-standard", "boleto:rule.str-route-large-boletos", "boleto:rule.siloc-file-exchange", "boleto:rule.pix-qr-on-boleto" ], "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.", "relations": [ { "type": "see_also", "to": "pix:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "boleto:src.nuclea-siloc-manual-leiautes", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "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.", "rules": [ "boleto:rule.participation-eligibility", "boleto:rule.direct-or-represented-settlement", "boleto:rule.dynamic-asset-links", "boleto:rule.convention-delegation" ], "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.", "relations": [ { "type": "see_also", "to": "pix:participants", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "boleto:src.bcb-resolucao-443", "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": "boleto:src.bcb-instrucao-normativa-611", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the two eligible asset types for dynamic-boleto links, art. 1." }, { "source": "boleto:src.convencao-cobranca-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": "boleto:src.nuclea-siloc", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms Nuclea operates SILOC and admits BCB-authorised institutions." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "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.", "rules": [ "boleto:rule.write-off", "boleto:rule.nonconforming-payment-reversal-attempt" ], "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].", "relations": [ { "type": "see_also", "to": "boleto:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "boleto:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "boleto:src.febraban-cnab240-v11-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": "boleto:src.convencao-cobranca-2021", "checked_on": "2026-09-19", "checked_by": "bancontact-boleto-validator", "notes": "Confirms the reversal-attempt procedure for a non-conforming payment, art. 34." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "boleto:return", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "boleto:rule.proposta-payment-is-acceptance", "boleto:rule.payer-claim", "boleto:rule.nonconforming-payment-reversal-attempt" ], "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].", "relations": [ { "type": "see_also", "to": "pix:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "boleto:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "boleto:consumer-law", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "boleto:src.bcb-resolucao-443", "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": "boleto:src.febraban-cnab240-v11-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": "boleto:src.convencao-cobranca-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "boleto:consumer-law", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "boleto:recall", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "boleto:return", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "boleto:rule.devolucao-same-system", "boleto:rule.devolucao-next-business-day", "boleto:rule.devolucao-convention-grounds", "boleto:rule.entry-rejection" ], "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.", "relations": [ { "type": "see_also", "to": "pix:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "boleto:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "boleto:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "boleto:src.bcb-resolucao-443", "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": "boleto:src.convencao-cobranca-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "boleto:finality", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "boleto:recall", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "boleto:refund", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "boleto:rule.str-route-large-boletos", "boleto:rule.netting-route-below-threshold", "boleto:rule.dynamic-always-nets", "boleto:rule.siloc-net-central-bank-money", "boleto:rule.siloc-settlement-timing", "boleto:rule.siloc-settlement-default", "boleto:rule.rights-and-duties-sources" ], "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.", "relations": [ { "type": "see_also", "to": "pix:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "boleto:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "boleto:hours", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "boleto:src.nuclea-siloc-regulamento", "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": "boleto:src.nuclea-siloc-manual-operacoes", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "boleto:finality", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "boleto:hours", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps:rail.eps", "id": "rail.eps", "class": "Rail", "rail": "eps", "name": "Austria eps-Überweisung", "governing_authority": "PSA Payment Services Austria GmbH", "country": "AT", "currency": "EUR", "operators": [ "PSA Payment Services Austria GmbH (eService Scheme Operator)" ], "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" ], "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "whole document", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "source_class": null, "effective_status_reason": null, "used_by": [] }, { "uid": "eps:exc.error-response", "id": "exc.error-response", "rail": "eps", "class": "Exception", "name": "Error response", "summary": "An eps request answered with an ErrorCode other than 000. For a payment initiation the answer is epsp:BankResponseDetails, from the debtor bank or from the Scheme Operator itself, and the transaction ends there; for a transaction details or confirmation status request the request fails and the payment is not affected. Errors the SO writes carry the prefix SO: in ErrorMsg.", "money_moves": false, "outcome": "Nothing is debited: an initiation that draws an error ends before the buyer authorises anything, and the merchant may send a new initiation once the fault is fixed. A failed status or details request leaves the payment where it was.", "relations": [ { "type": "initiated_by", "to": "eps:role.scheme-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "initiated_by", "to": "eps:role.debtor-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "eps:role.scheme-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "eps:role.debtor-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.error-in-synchronous-response", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.so-validates-initiation", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "sections 4.10, 6.5, 7.1.2, 7.1.4, 7.1.5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7, sections 4.10, 6.5, 7.1.2, 7.1.4 and 7.1.5, 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 on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms an ErrorCode other than 000 ends an initiation in BankResponseDetails, sent by the debtor bank or, with the SO: prefix, by the Scheme Operator, and that a failed status or details request leaves the underlying payment unaffected." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:rule.error-in-synchronous-response", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "eps-error:002", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-error:003", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-error:004", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-error:007", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-error:008", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-error:009", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-error:010", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-error:011", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-error:012", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-error:013", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-error:014", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "eps-error:015", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "eps-error:020", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-error:021", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "eps:exc.not-completed", "id": "exc.not-completed", "rail": "eps", "class": "Exception", "name": "Payment not completed", "summary": "The debtor bank ends the payment with status NOK in its confirmation: the buyer cancelled, before or after logging in, an error occurred, the merchant did not answer the vitality check, or the expiration time passed. The confirmation may carry an eps:StatusReason code saying why the payment was declined.", "money_moves": false, "outcome": "No credit transfer is executed, so there is nothing to return. The merchant receives the NOK confirmation through the Scheme Operator, the buyer is sent to the merchant's NOK URL, and the merchant may offer a new eps payment or another method.", "relations": [ { "type": "initiated_by", "to": "eps:role.debtor-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "eps:role.debtor-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "eps:role.buyer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "eps:role.scheme-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.debtor-bank-decides-execution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.expiration-window", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.no-transfer-if-merchant-unreachable", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.nok-ends-payment-without-transfer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.so-fraud-abort", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "sections 6.2.2.7, 6.2.2.8, 6.3.5, 7.1.7, 7.1.9, 7.1.11", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7, sections 6.2.2.7, 6.2.2.8, 6.3.5, 7.1.7, 7.1.9 and 7.1.11, read 2026-09-19. The Scheme Operator is listed as a decider because status reason 115 names it as aborting a payment.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the debtor bank ends a payment with NOK on buyer cancellation, an error, an unanswered vitality check or an expired window, optionally with a StatusReason code, and that no transfer executes." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:rule.expiration-window", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.so-fraud-abort", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:030", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-status-reason:031", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-status-reason:032", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-status-reason:110", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-status-reason:115", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-status-reason:120", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-status-reason:121", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-status-reason:122", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-status-reason:123", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "eps:exc.outcome-unknown", "id": "exc.outcome-unknown", "rail": "eps", "class": "Exception", "name": "Outcome unknown", "summary": "The Scheme Operator, not the bank, sends the merchant a confirmation with status UNKNOWN when the debtor bank's own confirmation has not reached it in time; the buyer is then redirected to the shop.", "money_moves": false, "outcome": "The UNKNOWN status itself moves nothing, but the transfer may already have been executed: a bank confirmation that arrives after the redirect is refused with HTTP 412 and never reaches the merchant. The merchant finds out with a confirmation status request, which from protocol version 2.6 works up to 42 days after processing, and should not start a second payment until then.", "relations": [ { "type": "initiated_by", "to": "eps:role.scheme-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "eps:role.scheme-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.unknown-on-late-confirmation", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.status-request-42-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "sections 6.2.2.7, 6.2.2.11 (usage of status code UNKNOWN), 6.12", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "eps:src.psa-eservices-technisches-beiblatt-1-8", "section": "section 6.2.1", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7, sections 6.2.2.7, 6.2.2.11 and 6.12; Technisches Beiblatt version 1.8, section 6.2.1; read 2026-09-19. money_moves is false for the status message; whether the transfer moved is exactly what is unknown.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the Scheme Operator, not the bank, writes status UNKNOWN when the debtor bank's confirmation has not arrived in time, and that a bank confirmation arriving after the redirect is rejected with HTTP 412 and never reaches the merchant." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:rule.unknown-on-late-confirmation", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:021", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:033", "type": "raised_in", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps:exc.refund-refused", "id": "exc.refund-refused", "rail": "eps", "class": "Exception", "name": "Refund request refused", "summary": "The Scheme Operator answers an EpsRefundRequest with an error in epsr:StatusCode of the epsr:EpsRefundResponse, so no payment order is created.", "money_moves": false, "outcome": "No money moves and the original eps payment stands. The merchant may send a corrected request where the ground allows, or repay the buyer outside eps.", "relations": [ { "type": "initiated_by", "to": "eps:role.scheme-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "eps:role.scheme-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.refund-answered-in-response", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.refund-original-completed-within-13-months", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.refund-cap-original-amount", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.refund-needs-bank-agreement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "eps:src.psa-eps-refundierung-1-0-1", "section": "sections 4.6, 7.2, 7.2.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "eps Refundierung version 1.0.1, sections 4.6, 7.2 and 7.2.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 on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-refundierung-1-0-1", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the Scheme Operator answers a refund request with an error code in epsr:StatusCode when a check fails, so no payment order is created and the original eps payment stands." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:rule.refund-answered-in-response", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "eps-refund-error:004", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-refund-error:007", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-refund-error:009", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-refund-error:010", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-refund-error:011", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-refund-error:012", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-refund-error:013", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-refund-error:015", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-refund-error:020", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-refund-error:021", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-refund-error:022", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "eps:exc.refund", "id": "exc.refund", "rail": "eps", "class": "Exception", "name": "Refund", "summary": "A merchant-initiated repayment of a completed eps payment, in full or in part: the Scheme Operator checks the request and writes a new SEPA credit transfer order from the merchant's registered account to the buyer's account, which the merchant's bank executes.", "money_moves": true, "outcome": "Money moves back to the buyer as a new credit transfer, not as a reversal of the original. A success answer from the SO means only that the merchant's bank accepted the order; its own limit and block checks, or a manual release, can still stop the payment.", "relations": [ { "type": "initiated_by", "to": "eps:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "eps:role.scheme-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "eps:role.creditor-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.refund-merchant-initiated-via-so", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.refund-needs-bank-agreement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.refund-original-completed-within-13-months", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.refund-cap-original-amount", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.refund-as-new-sct", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.refund-acceptance-not-guarantee", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "eps:src.psa-eps-refundierung-1-0-1", "section": "sections 2.2, 7.2, 8.1, 8.2, 8.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Refundierung version 1.0.1, sections 2.2, 7.2, 8.1, 8.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 on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-refundierung-1-0-1", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms a merchant-initiated refund becomes a new SCT credit transfer order from the merchant's registered account to the buyer, and that a successful SO answer means only the merchant's bank accepted the order, since its own limit and block checks can still stop the payment." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:rule.refund-acceptance-not-guarantee", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.refund-as-new-sct", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps:role.buyer", "id": "role.buyer", "rail": "eps", "class": "Role", "name": "Buyer", "summary": "The payer: the buyer or ordering customer, whose account at the debtor bank is debited. The buyer always logs in and authorises the transfer in their own bank's online banking or banking app, with payee, amount and reference filled in and locked; eps messages carry none of the buyer's banking data to the merchant, apart from the optional IBAN, BIC and name a confirmation may pass on for refunds.", "kind": "party", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "sections 1.1, 1.2, 6.2.1.1.3, 6.2.2.9 to 6.2.2.11, 8", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7, sections 1.1, 1.2, 6.2.1.1.3, 6.2.2.9 to 6.2.2.11 and 8, 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 on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the buyer as the payer who authorises the transfer in their own bank's online banking, with payee, amount and reference locked, and that eps carries none of the buyer's banking data to the merchant apart from the optional IBAN, BIC and name a confirmation passes on for refunds." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:exc.not-completed", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.buyer-authenticates-at-own-bank", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.consumer-rights-outside-eps", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.three-confirmation-attempts", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps:role.creditor-bank", "id": "role.creditor-bank", "rail": "eps", "class": "Role", "name": "Creditor bank or eps acquirer", "summary": "The merchant's side: the bank or payment institution that holds the merchant's account and signs the eps merchant contract, or an eps acquirer that contracts with the merchant instead. For refunds it is the merchant bank: refunds must be agreed with it, it enables the merchant at the Scheme Operator, and it receives and executes (or stops) the refund payment order.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "sections 1.2, 3.1, 3.4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "eps:src.psa-eps-refundierung-1-0-1", "section": "sections 2.3, 3.2, 8.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7, sections 1.2, 3.1 and 3.4; eps Refundierung version 1.0.1, sections 2.3, 3.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 on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the creditor bank or eps acquirer as the merchant's contracting side, holding the merchant's account or signing the merchant contract in its place." }, { "source": "eps:src.psa-eps-refundierung-1-0-1", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms that for a refund the merchant bank must agree to support refunds, enable the merchant at the Scheme Operator, and that it receives the payment order for execution and may require a manual release." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:exc.refund", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.bank-legal-framework", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.merchant-contract", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.refund-acceptance-not-guarantee", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.refund-as-new-sct", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.refund-needs-bank-agreement", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps:role.debtor-bank", "id": "role.debtor-bank", "rail": "eps", "class": "Role", "name": "Debtor bank", "summary": "The buyer's bank or payment institution, offering eps in its online banking. It answers the initiation, shows the prefilled payment to the buyer, sends the vitality check, executes the credit transfer, and writes and digitally signs the confirmation with status OK or NOK. Under a guaranteed merchant contract it stands behind a payment it has confirmed with OK.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "sections 1.2, 6.2.2, 6.2.2.7, 7.1.4, 7.1.7, 7.1.10, 7.1.11", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7, sections 1.2, 6.2.2, 7.1.4, 7.1.7, 7.1.10 and 7.1.11, 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 on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the debtor bank answers the initiation, runs the vitality check, executes the transfer only after a positive vitality check, and signs the confirmation with OK or NOK, and that a guaranteed merchant contract has the bank stand behind an OK." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:exc.error-response", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "eps:exc.error-response", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "eps:exc.not-completed", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "eps:exc.not-completed", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.bank-executes-after-vitality-check", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.bank-legal-framework", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.buyer-authenticates-at-own-bank", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.debtor-bank-decides-execution", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.debtor-bank-signs-confirmation", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.eps4mobile-flows", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.error-in-synchronous-response", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.expiration-window", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.funds-move-as-sepa-credit-transfer", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.guarantee-on-ok", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.no-transfer-if-merchant-unreachable", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.nok-ends-payment-without-transfer", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.ok-only-after-authorisation-and-vitality-check", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.redirect-error-values", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.so-routing-mandatory", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.so-timeouts-20-seconds", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.status-values", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.three-confirmation-attempts", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.vok-without-guarantee", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps-error:003", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-error:004", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-error:007", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-error:008", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-error:009", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-error:010", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-error:011", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-error:012", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-error:014", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-error:015", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:030", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:031", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:032", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:110", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:120", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:121", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:122", "type": "returned_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps:role.merchant", "id": "role.merchant", "rail": "eps", "class": "Role", "name": "Merchant", "summary": "The payee: a web shop or an e-government body, the beneficiary credited by the transfer. It builds the payment initiation, sends every message through the Scheme Operator, answers the vitality check, acknowledges the payment confirmation, and alone can start a refund. It needs an eps merchant contract with an eps bank or an acquirer.", "kind": "party", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "sections 1.2, 3.4, 7.1.2, 7.1.9, 7.1.13", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "eps:src.psa-eps-refundierung-1-0-1", "section": "section 2.2", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7, sections 1.2, 3.4, 7.1.2, 7.1.9 and 7.1.13; eps Refundierung version 1.0.1, section 2.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 on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the merchant builds the initiation, sends everything through the Scheme Operator, must answer the vitality check, and confirms receipt of the payment confirmation, and that offering eps needs a merchant contract with an eps bank or acquirer." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:exc.refund", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.bank-executes-after-vitality-check", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.field-length-caps", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.initiation-clock-skew-3-minutes", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.merchant-confirms-confirmation", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.merchant-contract", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.merchant-offers-all-banks", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.no-transfer-if-merchant-unreachable", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.refund-cap-original-amount", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.refund-merchant-initiated-via-so", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.refund-needs-bank-agreement", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.refund-request-time-3-hours", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.so-routing-mandatory", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.so-timeouts-20-seconds", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.status-request-42-days", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.three-confirmation-attempts", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps:role.scheme-operator", "id": "role.scheme-operator", "rail": "eps", "class": "Role", "name": "Scheme Operator", "summary": "PSA Payment Services Austria GmbH acting as eService Scheme Operator (SO): the central routing service every eps message passes through. It validates initiations, stands in for the merchant toward the debtor bank, forwards the bank's confirmation unchanged, writes status UNKNOWN when a bank's confirmation is late, answers status requests, and turns refund requests into SEPA credit transfer orders. It holds no funds [Inference from its description as a routing service].", "kind": "operator", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "sections 1.2, 3.1, 5 (Maintenance), 6.2.2.11, 7.1.2, 7.1.3, 7.1.12", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "eps:src.psa-eps-refundierung-1-0-1", "section": "sections 2.3, 8", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7, sections 1.2, 3.1, 5, 6.2.2.11, 7.1.2, 7.1.3 and 7.1.12; eps Refundierung version 1.0.1, sections 2.3 and 8; read 2026-09-19. That the SO holds no funds is Orca's reading.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms PSA as the central routing service every eps message must pass through, validating initiations, standing in for the merchant toward the debtor bank, forwarding the bank's confirmation unchanged, and writing UNKNOWN when a bank confirmation is late." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:exc.error-response", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "eps:exc.error-response", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "eps:exc.not-completed", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "eps:exc.outcome-unknown", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "eps:exc.outcome-unknown", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "eps:exc.refund-refused", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "eps:exc.refund-refused", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "eps:exc.refund", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.bank-legal-framework", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.debtor-bank-signs-confirmation", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.eps4mobile-flows", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.error-in-synchronous-response", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.redirect-error-values", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.refund-answered-in-response", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.refund-as-new-sct", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.refund-merchant-initiated-via-so", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.refund-original-completed-within-13-months", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.so-fraud-abort", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.so-only-error-013", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.so-routing-mandatory", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.so-timeouts-20-seconds", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.so-validates-initiation", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.status-request-42-days", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.status-values", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.unknown-on-late-confirmation", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "eps-error:002", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-error:004", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-error:007", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-error:008", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-error:009", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-error:010", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-error:011", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-error:012", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-error:013", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-error:014", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-error:015", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-error:020", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-error:021", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-refund-error:004", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-refund-error:007", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-refund-error:009", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-refund-error:010", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-refund-error:011", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-refund-error:012", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-refund-error:013", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-refund-error:015", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-refund-error:020", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-refund-error:021", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-refund-error:022", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps-status-reason:021", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:031", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:032", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:033", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:115", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:120", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:121", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:122", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:123", "type": "returned_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps:rule.bank-executes-after-vitality-check", "id": "rule.bank-executes-after-vitality-check", "rail": "eps", "class": "Rule", "name": "The debtor bank executes after a positive vitality check", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "sections 7.1.7, 7.1.8, 7.1.9, 7.1.10", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.debtor-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), sections 7.1.7 to 7.1.10, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the debtor bank sends the vitality check to the merchant's confirmation URL through the Scheme Operator after the buyer authorises, and settles the credit transfer only once it has the merchant's positive answer." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps:rule.bank-legal-framework", "id": "rule.bank-legal-framework", "rail": "eps", "class": "Rule", "name": "Banks join under PSA's eServices legal framework", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "sections 1.2 (eService legal framework), 3.2, 3.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.debtor-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.creditor-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.scheme-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), sections 1.2, 3.2 and 3.3, read 2026-09-19. The agreement itself was not read.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms a bank must sign the eServices legal framework agreement with PSA and approve the eps product sheet before offering eps, after which the Scheme Operator registers it for testing or production." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps:rule.buyer-authenticates-at-own-bank", "id": "rule.buyer-authenticates-at-own-bank", "rail": "eps", "class": "Rule", "name": "The buyer authorises in their own bank, with the payment locked", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "sections 1.1, 6.2.1.1.2, 6.2.1.1.3, 6.2.2.9 to 6.2.2.11, 8", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "eps:src.psa-eps-privatkunden-page", "section": "Häufig gestellte Fragen", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.debtor-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.buyer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), sections 1.1, 6.2.1.1.2, 6.2.1.1.3, 6.2.2.9 to 6.2.2.11 and 8; PSA Privatkunden page FAQ; read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the buyer authenticates only with their own bank's methods, that payee, amount and reference cannot be changed by the buyer, and that eps passes none of the buyer's banking data to any third party." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps:rule.consumer-rights-outside-eps", "id": "rule.consumer-rights-outside-eps", "rail": "eps", "class": "Rule", "name": "Consumer rights sit outside eps", "statement": "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].", "rests_on": "law", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "sections 1.1, 7.1.7", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "eps:src.psa-eps-privatkunden-page", "section": "Häufig gestellte Fragen", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.buyer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct:consumer-law", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), sections 1.1 and 7.1.7, and the PSA Privatkunden page, read 2026-09-19, for how the buyer authorises. The legal conclusion is Orca's inference; 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 on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the buyer orders the transfer directly from their own account at their own bank, which is the basis for treating a payment dispute as a matter between the buyer and their bank." }, { "source": "eps:src.psa-eps-privatkunden-page", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms PSA's own consumer FAQ directs a buyer with a question about an eps payment to their own bank, not to PSA." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps:rule.debtor-bank-decides-execution", "id": "rule.debtor-bank-decides-execution", "rail": "eps", "class": "Rule", "name": "The debtor bank decides whether to execute", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "sections 6.2.2.7, 7.1.7, 7.1.11", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.debtor-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), sections 6.2.2.7, 7.1.7 and 7.1.11, 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 on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the debtor bank must answer with NOK, without first sending a vitality check, when the buyer cancels before or after login or an error occurs in online banking." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:exc.not-completed", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:030", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:110", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps:rule.debtor-bank-signs-confirmation", "id": "rule.debtor-bank-signs-confirmation", "rail": "eps", "class": "Rule", "name": "The bank signs its confirmation and names itself", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "sections 4.10 (mapping eps confirmation), 6.2.2, 6.7, 7.1.7, 7.1.11, 7.1.12", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.debtor-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.scheme-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), sections 4.10, 6.2.2, 6.7, 7.1.7, 7.1.11 and 7.1.12, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the confirmation must be digitally signed and carry the bank's BIC or another approving identifier, that a confirmation missing this is refused with HTTP 412, and that the Scheme Operator forwards a valid confirmation unchanged so the merchant can check the signature." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps-status-reason:122", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:123", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps:rule.eps-fields-map-to-pacs008", "id": "rule.eps-fields-map-to-pacs008", "rail": "eps", "class": "Rule", "name": "eps fields map onto the SCT pacs.008", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "sections 6.2.1.1.3, 9.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), sections 6.2.1.1.3 and 9.1, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the annex maps the beneficiary BIC, name and IBAN, the structured and unstructured references, and the amount and currency onto the SCT pacs.008 fields, and that eps defaults to charge code SHA where SCT uses SLEV." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps:rule.eps4mobile-flows", "id": "rule.eps4mobile-flows", "rail": "eps", "class": "Rule", "name": "eps4mobile: QR code and app switch", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "sections 6.4 (epsp:TransactionID, epsp:QRCodeUrl), 6.9, 6.10, 6.11, 8", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.scheme-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.debtor-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), sections 6.4, 6.9 to 6.11 and 8, 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 on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the Scheme Operator generates a TransactionId and a QRCodeUrl with the epspayment scheme for mobile flows, returned to the merchant, letting the buyer approve by scanning a QR code or switching to a banking app, with the bank able to fetch transaction details." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps:rule.error-in-synchronous-response", "id": "rule.error-in-synchronous-response", "rail": "eps", "class": "Rule", "name": "Errors come back in the answer to the request", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "sections 4.10, 6.5, 7.1.2, 7.1.4, 7.1.5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "eps:exc.error-response", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.scheme-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.debtor-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), sections 4.10, 6.5, 7.1.2, 7.1.4 and 7.1.5, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the Scheme Operator or the debtor bank returns an ErrorCode and ErrorMsg in the answer to the request itself, with the SO: prefix marking a Scheme Operator error, and that an initiation drawing an error ends there." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:exc.error-response", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-error:002", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-error:003", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-error:004", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-error:007", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-error:008", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-error:009", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-error:010", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-error:011", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-error:012", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-error:013", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-error:014", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-error:015", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-error:020", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-error:021", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps:rule.expiration-window", "id": "rule.expiration-window", "rail": "eps", "class": "Rule", "name": "Expiration time: 5 to 60 minutes", "statement": "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.", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "sections 6.3.5, 7.1.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "eps:src.psa-eservices-technisches-beiblatt-1-8", "section": "section 6.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "eps:exc.not-completed", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.debtor-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), sections 6.3.5 and 7.1.2; Technisches Beiblatt version 1.8 (November 2025), section 6.1; read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the merchant may set an expiration time between 5 and 60 minutes after initiation, that the debtor bank checks it when the buyer authorises rather than at initiation, and that the bank must refuse OK and send NOK once it has passed." }, { "source": "eps:src.psa-eservices-technisches-beiblatt-1-8", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the valid expiration window is initiation time plus 5 minutes at the earliest and initiation time plus 60 minutes at the latest." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:exc.not-completed", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-error:012", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:030", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:031", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:032", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:110", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:120", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:121", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:122", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:123", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps:rule.field-length-caps", "id": "rule.field-length-caps", "rail": "eps", "class": "Rule", "name": "Data caps: URLs, references and names", "statement": "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.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "sections 4.6, 6.1, 6.2.1.1.2 (epi:BeneficiaryNameAddressText), 6.2.1.1.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), sections 4.6, 6.1, 6.2.1.1.2 and 6.2.1.1.3, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "2026-03-25", "effective_to": null, "effective_note": "The eps documents do not date this value. 2026-03-25 is the date PSA's download page lists for the version 2.7 guideline read, used because the limits facet needs an ISO date; it is 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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms URL fields are capped at 512 characters, structured references at 35 and unstructured ones at 140 characters, and that Austrian online banking shows at most 70 of the beneficiary name field's characters even though the field allows more." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps-error:002", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps:rule.funds-move-as-sepa-credit-transfer", "id": "rule.funds-move-as-sepa-credit-transfer", "rail": "eps", "class": "Rule", "name": "The money moves as a SEPA credit transfer", "statement": "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].", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "sections 1.1, 3.1, 7.1.7, 7.1.10, 9.1 (mapping table eps to SCT pacs.008)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.debtor-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct-inst:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct-inst:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), sections 1.1, 3.1, 7.1.7, 7.1.10 and 9.1, read 2026-09-19. The SCT rules themselves are in the linked sepa-sct facts, which carry their own citations; no eps document is a source for an SCT rule.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the buyer's own bank executes a SEPA credit transfer that the buyer authorised in online banking, and that the guideline maps the payment fields onto the SCT interbank message pacs.008." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps:rule.guarantee-on-ok", "id": "rule.guarantee-on-ok", "rail": "eps", "class": "Rule", "name": "Debtor bank guarantee on status OK", "statement": "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.", "rests_on": "rule", "facet": "liability", "parameters": { "liability_holder": { "role": "eps:role.debtor-bank", "condition": "status OK sent under a guaranteed eps merchant contract", "text": "the debtor bank, for a payment it confirmed with OK under a guaranteed merchant contract" } }, "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "section 1.2 (Guaranteed Payment); section 6.3.1; section 7.1.12", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.debtor-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), sections 1.2, 6.3.1 and 7.1.12, read 2026-09-19. The merchant contracts that carry the guarantee terms are not public and were not read.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the guarantee comes from the merchant contract, not from a per-payment field, since the field that would request a guarantee payment by payment is marked for future use and not supported in online banking." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps:rule.initiation-clock-skew-3-minutes", "id": "rule.initiation-clock-skew-3-minutes", "rail": "eps", "class": "Rule", "name": "Initiation refused beyond 3 minutes of clock difference", "statement": "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].", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eservices-technisches-beiblatt-1-8", "section": "section 3.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Technisches Beiblatt version 1.8 (November 2025), section 3.1, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eservices-technisches-beiblatt-1-8", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the Scheme Operator actively rejects an initiation whose merchant-set creation time differs from its own processing time by more than 3 minutes, and that automated time synchronisation is strongly recommended." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps:rule.merchant-confirms-confirmation", "id": "rule.merchant-confirms-confirmation", "rail": "eps", "class": "Rule", "name": "The merchant must acknowledge the confirmation", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "sections 6.4 (epsp:ConfirmationUrl, epsp:TransactionOkUrl), 6.8, 7.1.13.1, 7.1.13.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), sections 6.4, 6.8 and 7.1.13, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the merchant must answer the confirmation with a ShopResponseDetails returning the session ID, status code and payment reference it received, or an error text if it cannot validate the confirmation." } ] }, "source_class": "authoritative_primary", "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "eps:rule.merchant-contract", "id": "rule.merchant-contract", "rail": "eps", "class": "Rule", "name": "Merchants need an eps merchant contract", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "preamble; sections 1.2, 3.4, 7.1.12", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "eps:src.psa-eps-haendler-page", "section": "Häufig gestellte Fragen", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.creditor-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), preamble and sections 1.2, 3.4 and 7.1.12; PSA Händler page FAQ; read 2026-09-19. No merchant contract was read.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms a merchant must conclude an eps merchant contract with an eps bank or acquirer to offer eps, and that the guaranteed eps payment option is handled by that contract." }, { "source": "eps:src.psa-eps-haendler-page", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the merchant page treats the eps contract and its price as a matter between the merchant and its bank." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps:rule.merchant-offers-all-banks", "id": "rule.merchant-offers-all-banks", "rail": "eps", "class": "Rule", "name": "The buyer chooses the bank, from all eps banks", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "sections 3.5, 7.1, 7.2, 7.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), sections 3.5, 7.1, 7.2 and 7.3, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the guideline states in its own words that the merchant must provide all available eps debtor banks in its own bank selection, taken from the list the Scheme Operator provides, as an alternative to the central or widget selection." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps-error:015", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps:rule.no-cancel-after-ok", "id": "rule.no-cancel-after-ok", "rail": "eps", "class": "Rule", "name": "No eps message undoes a payment after OK", "statement": "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.", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "sections 5, 6.4 to 6.13, 7.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "eps:src.psa-eps-haendler-page", "section": "section on the real-time execution guarantee", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), sections 5, 6.4 to 6.13 and 7.1, read 2026-09-19, for the absence of any cancel message; PSA Händler page, read 2026-09-19, for the irrevocability claim.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms no message in the guideline's message set lets any party withdraw or cancel a payment once the debtor bank has confirmed it." }, { "source": "eps:src.psa-eps-haendler-page", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the merchant page describes eps as carrying a real-time execution guarantee, under which payment orders the bank's system has checked and accepted are confirmed online at once and carried out irrevocably." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps:rule.no-eps-return-or-recall", "id": "rule.no-eps-return-or-recall", "rail": "eps", "class": "Rule", "name": "eps defines no return and no recall", "statement": "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].", "rests_on": "rule", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "sections 5, 6.4 to 6.13", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "eps:src.psa-eps-refundierung-1-0-1", "section": "section 7", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), sections 5 and 6.4 to 6.13; eps Refundierung version 1.0.1 (22 October 2018), section 7; read 2026-09-19. A statement of absence.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the guideline's message set defines no message by which a completed eps payment is returned or recalled." }, { "source": "eps:src.psa-eps-refundierung-1-0-1", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the refund specification's only way to move money back is the merchant-initiated refund, built as a new payment order, not a return or recall message." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps:rule.no-scheme-amount-limit", "id": "rule.no-scheme-amount-limit", "rail": "eps", "class": "Rule", "name": "No amount limit in the eps standard", "statement": "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].", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "sections 6.2.1.1.3 (epi:InstructedAmount), 7.1.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), sections 6.2.1.1.3 and 7.1.2, read 2026-09-19. A statement of absence.", "confidence": "medium" }, "currency": { "effective_since": "2026-03-25", "effective_to": null, "effective_note": "The eps documents do not date this value. 2026-03-25 is the date PSA's download page lists for the version 2.7 guideline read, used because the limits facet needs an ISO date; it is 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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the instructed amount is defined only as a decimal with an ISO 4217 currency code, with no minimum or maximum stated in the guideline or the Scheme Operator's initiation checks." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps:rule.no-transfer-if-merchant-unreachable", "id": "rule.no-transfer-if-merchant-unreachable", "rail": "eps", "class": "Rule", "name": "No transfer when the merchant misses the vitality check", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "section 7.1.9", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.debtor-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), section 7.1.9, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms that when the merchant does not answer the vitality check in time, the Scheme Operator tells the debtor bank with HTTP 412, the bank sends the buyer to the merchant's NOK URL, no credit transfer executes, and the buyer's TAN is marked used." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:exc.not-completed", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:032", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:121", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps:rule.nok-ends-payment-without-transfer", "id": "rule.nok-ends-payment-without-transfer", "rail": "eps", "class": "Rule", "name": "A failed payment ends with NOK, not a return", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "sections 6.2.2.7, 6.2.2.8, 7.1.7, 7.1.11", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.debtor-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), sections 6.2.2.7, 6.2.2.8, 7.1.7 and 7.1.11, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms a payment the debtor bank ends with NOK may carry a StatusReason code and that nothing was debited." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:exc.not-completed", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps:rule.ok-only-after-authorisation-and-vitality-check", "id": "rule.ok-only-after-authorisation-and-vitality-check", "rail": "eps", "class": "Rule", "name": "Status OK only after authorisation, vitality check and execution", "statement": "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.", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "sections 7.1.7, 7.1.10, 7.1.11", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.debtor-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), sections 7.1.7, 7.1.10 and 7.1.11, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the debtor bank may send OK only after the buyer has authorised the transfer, the merchant has answered the vitality check, and the bank has executed the transfer, so OK reports a transfer already carried out." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps:rule.processor-no-chargebacks", "id": "rule.processor-no-chargebacks", "rail": "eps", "class": "Rule", "name": "Processors report no chargebacks on EPS", "statement": "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.", "rests_on": "practice", "facet": "return", "relations": [ { "type": "sourced_from", "to": "eps:src.stripe-eps-payments", "section": "Disputes section and payment method properties (dispute support)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "eps:src.adyen-eps", "section": "feature table (Chargebacks column)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Stripe Docs, EPS payments, and Adyen Docs, EPS, both read 2026-09-19. Secondary sources describing processor practice.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.stripe-eps-payments", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms Stripe states EPS carries no dispute support because the buyer authenticates with their bank, so it does not turn into a chargeback withdrawn from the Stripe account." }, { "source": "eps:src.adyen-eps", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms Adyen's feature table marks chargebacks as not supported for EPS while marking refunds, partial refunds and multiple partial refunds as supported." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps:rule.processor-refund-windows", "id": "rule.processor-refund-windows", "rail": "eps", "class": "Rule", "name": "Processor refund windows and options", "statement": "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.", "rests_on": "practice", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "eps:src.stripe-eps-payments", "section": "Refunds section; payment method properties", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "eps:src.adyen-eps", "section": "feature table (Refunds, Partial refunds, Multiple partial refunds)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Stripe Docs, EPS payments, and Adyen Docs, EPS, both read 2026-09-19. Secondary sources describing 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 on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.stripe-eps-payments", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms Stripe allows EPS refunds and partial refunds up to 180 days after the original payment." }, { "source": "eps:src.adyen-eps", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms Adyen's feature table marks refunds, partial refunds and multiple partial refunds as supported for EPS." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps:rule.redirect-error-values", "id": "rule.redirect-error-values", "rail": "eps", "class": "Rule", "name": "Redirect error values ERROR1 to ERROR3", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "sections 4.10, 7.1.15.2, 7.1.16, 7.2.5, 7.2.7", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.debtor-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.scheme-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), sections 4.10, 7.1.15.2, 7.1.16, 7.2.5 and 7.2.7, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms ERROR1 means the merchant could not be reached with the confirmation, ERROR2 means faulty XML or a broken signature, ERROR3 means the buyer cancelled in online banking, and that with central bank selection the Scheme Operator also uses ERROR3 when the chosen bank did not answer or failed while processing the initiation." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps:rule.refund-acceptance-not-guarantee", "id": "rule.refund-acceptance-not-guarantee", "rail": "eps", "class": "Rule", "name": "A successful refund answer is not a guarantee of payment", "statement": "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.", "rests_on": "rule", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-refundierung-1-0-1", "section": "sections 7.2, 7.2.1, 8.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "eps:exc.refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.creditor-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Refundierung version 1.0.1 (22 October 2018), sections 7.2, 7.2.1 and 8.3, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-refundierung-1-0-1", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms code 000 in the refund response confirms only that the merchant's bank accepted the payment order, and that limit and block checks on the merchant's account can still lead to the order being rejected." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:exc.refund", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps:rule.refund-answered-in-response", "id": "rule.refund-answered-in-response", "rail": "eps", "class": "Rule", "name": "Refund errors come back in the refund response", "statement": "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.", "rests_on": "rule", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-refundierung-1-0-1", "section": "sections 4.6, 7.2, 7.2.1, 7.2.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "eps:exc.refund-refused", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.scheme-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Refundierung version 1.0.1 (22 October 2018), sections 4.6 and 7.2, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-refundierung-1-0-1", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the Scheme Operator answers the refund request in the EpsRefundResponse with code 000 when the merchant's bank accepted the order or with an error code and message when it did not." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:exc.refund-refused", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-refund-error:004", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-refund-error:007", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-refund-error:009", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-refund-error:010", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-refund-error:011", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-refund-error:012", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-refund-error:013", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-refund-error:015", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-refund-error:020", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-refund-error:021", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-refund-error:022", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps:rule.refund-as-new-sct", "id": "rule.refund-as-new-sct", "rail": "eps", "class": "Rule", "name": "A refund is a new SEPA credit transfer order", "statement": "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.", "rests_on": "rule", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-refundierung-1-0-1", "section": "sections 8.2, 8.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "sections 6.2.2.9 to 6.2.2.11", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "eps:exc.refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.scheme-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.creditor-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Refundierung version 1.0.1 (22 October 2018), sections 8.2 and 8.3; eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), sections 6.2.2.9 to 6.2.2.11; read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-refundierung-1-0-1", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the Scheme Operator builds an SCT pain.001 file from the merchant's account to the buyer's account, taking the buyer's name and IBAN from the original bank confirmation and the references from the original initiation, marked with category purpose EPAY, and delivers it to the merchant's bank by SFTP for processing that may need a manual release." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:exc.refund", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps:rule.refund-cap-original-amount", "id": "rule.refund-cap-original-amount", "rail": "eps", "class": "Rule", "name": "Refunds may not exceed the original amount", "statement": "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.", "rests_on": "rule", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-refundierung-1-0-1", "section": "sections 4.6 (code 022), 7.1.4, 8.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Refundierung version 1.0.1 (22 October 2018), sections 4.6, 7.1.4 and 8.1, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-refundierung-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, with a request that would refused as code 022." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:exc.refund-refused", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps:exc.refund", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-refund-error:022", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps:rule.refund-merchant-initiated-via-so", "id": "rule.refund-merchant-initiated-via-so", "rail": "eps", "class": "Rule", "name": "Only the merchant starts a refund, through the Scheme Operator", "statement": "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.", "rests_on": "rule", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-refundierung-1-0-1", "section": "sections 1, 2.2, 7.1.6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.scheme-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Refundierung version 1.0.1 (22 October 2018), sections 1, 2.2 and 7.1.6, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-refundierung-1-0-1", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms only the merchant may request a refund, authorised with its PIN, and that the Scheme Operator checks the transaction and the amount before sending the merchant's bank a payment order to the buyer's account." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:exc.refund", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-refund-error:004", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-refund-error:020", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps:rule.refund-needs-bank-agreement", "id": "rule.refund-needs-bank-agreement", "rail": "eps", "class": "Rule", "name": "Refunds must be agreed with and enabled by the merchant's bank", "statement": "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.", "rests_on": "rule", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-refundierung-1-0-1", "section": "sections 3.2, 7.1.3, 8.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.creditor-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Refundierung version 1.0.1 (22 October 2018), sections 3.2, 7.1.3 and 8.1, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-refundierung-1-0-1", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms refunding eps payments must be agreed in the merchant's bank contract, that the bank must enable the merchant at the Scheme Operator, and that the debited account must be an IBAN registered for the merchant there." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:exc.refund-refused", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps:exc.refund", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-refund-error:010", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-refund-error:011", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-refund-error:015", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps:rule.refund-original-completed-within-13-months", "id": "rule.refund-original-completed-within-13-months", "rail": "eps", "class": "Rule", "name": "Refund only of a completed payment under 13 months old", "statement": "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].", "rests_on": "rule", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-refundierung-1-0-1", "section": "sections 4.6 (code 021), 8.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.scheme-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Refundierung version 1.0.1 (22 October 2018), sections 4.6 and 8.1, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-refundierung-1-0-1", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the Scheme Operator refunds only a completed eps payment made less than 13 months earlier, and that a payment not yet completed is refused with code 021." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:exc.refund-refused", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps:exc.refund", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-refund-error:021", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps:rule.refund-request-time-3-hours", "id": "rule.refund-request-time-3-hours", "rail": "eps", "class": "Rule", "name": "Refund request refused beyond 3 hours of clock difference", "statement": "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.", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-refundierung-1-0-1", "section": "sections 4.6 (code 012), 7.1.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Refundierung version 1.0.1 (22 October 2018), sections 4.6 and 7.1.1, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-refundierung-1-0-1", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the Scheme Operator checks the refund request's creation time against its own server time and refuses the request with code 012 when they differ by more than 3 hours." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps-refund-error:012", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps:rule.so-fraud-abort", "id": "rule.so-fraud-abort", "rail": "eps", "class": "Rule", "name": "The Scheme Operator may abort for a possible fraud check", "statement": "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].", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "section 6.2.2.8 (ReasonCode 115)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "eps:exc.not-completed", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.scheme-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), section 6.2.2.8, read 2026-09-19. The rule rests only on the code's own meaning; the timing wording is Orca's reading [Inference].", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the guideline lists a StatusReason code for a transaction the routing service aborted for a possible fraud check, with no criteria given for when this happens." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:exc.not-completed", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:115", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps:rule.so-only-error-013", "id": "rule.so-only-error-013", "rail": "eps", "class": "Rule", "name": "Error 013 is the Scheme Operator's alone", "statement": "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].", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "sections 6.5, 7.1.4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.scheme-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), sections 6.5 and 7.1.4, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the guideline marks error 013 as usable only by the Scheme Operator and explicitly not by the debtor bank, with no cross-border case defined." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps-error:013", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps:rule.so-routing-mandatory", "id": "rule.so-routing-mandatory", "rail": "eps", "class": "Rule", "name": "Every eps message goes through the Scheme Operator", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "preamble; sections 3.1, 7.1.3, 7.2.5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.scheme-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.debtor-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), preamble and sections 3.1, 7.1.3 and 7.2.5, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms all eps XML messages must be routed via the central Scheme Operator, which acts as the merchant toward the debtor bank, replacing the merchant's identifiers and signing outgoing messages, and journals every message." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps:rule.so-timeouts-20-seconds", "id": "rule.so-timeouts-20-seconds", "rail": "eps", "class": "Rule", "name": "Connection and read timeouts of 20 seconds", "statement": "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.", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eservices-technisches-beiblatt-1-8", "section": "sections 5.2.1, 5.2.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "sections 4.5, 7.1.3, 7.1.5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.debtor-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.scheme-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Technisches Beiblatt version 1.8 (November 2025), section 5.2; eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), sections 4.5, 7.1.3 and 7.1.5; read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eservices-technisches-beiblatt-1-8", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the connection timeout and the read timeout are both set uniformly at 20 seconds for all of PSA's e-Services." }, { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms a debtor bank that does not answer an initiation within the timeout draws error 008 for the merchant, described by the Scheme Operator's table as covering an http timeout among other causes." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps-error:008", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-error:014", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:031", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:032", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:121", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps:rule.so-validates-initiation", "id": "rule.so-validates-initiation", "rail": "eps", "class": "Rule", "name": "The Scheme Operator validates each initiation", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "sections 7.1.2, 7.2.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.scheme-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), sections 7.1.2 and 7.2.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 on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the Scheme Operator checks merchant authorisation, the registered credit account, the future-date permission and the expiration time before an initiation reaches a bank, answering a failed check with an error code." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:exc.error-response", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-error:004", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-error:010", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-error:012", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps:rule.status-request-42-days", "id": "rule.status-request-42-days", "rail": "eps", "class": "Rule", "name": "Status can be asked for up to 42 days", "statement": "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.", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eservices-technisches-beiblatt-1-8", "section": "section 6.2.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "sections 6.12, 6.13", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.scheme-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Technisches Beiblatt version 1.8 (November 2025), section 6.2.1; eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), sections 6.12 and 6.13; read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eservices-technisches-beiblatt-1-8", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms that from protocol version 2.6 a status request is possible up to 42 days after processing, while up to version 2.5 no such request is supported and the confirmation is only pushed." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:exc.outcome-unknown", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-error:020", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-error:021", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:021", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:033", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps:rule.status-values", "id": "rule.status-values", "rail": "eps", "class": "Rule", "name": "Status values OK, VOK, NOK and UNKNOWN", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "sections 6.2.2.7, 6.2.2.8, 7.1.12", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.debtor-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.scheme-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), sections 6.2.2.7, 6.2.2.8 and 7.1.12, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the confirmation carries one of OK, VOK, NOK or UNKNOWN, that the debtor bank itself sends only OK or NOK, that UNKNOWN comes from the Scheme Operator, and that a decline may add a StatusReason code." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps:rule.three-confirmation-attempts", "id": "rule.three-confirmation-attempts", "rail": "eps", "class": "Rule", "name": "Three attempts to deliver the confirmation", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "section 7.1.13", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.debtor-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.buyer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), section 7.1.13, read 2026-09-19.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the debtor bank has up to 3 attempts to deliver its confirmation within the timeout, and that after the third the bank tells the buyer the transfer executed but the merchant could not be informed, leaving further steps to buyer and merchant." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps:rule.unknown-on-late-confirmation", "id": "rule.unknown-on-late-confirmation", "rail": "eps", "class": "Rule", "name": "UNKNOWN when the bank's confirmation is late", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "sections 6.2.2.11 (usage of status code UNKNOWN), 6.3.5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "eps:exc.outcome-unknown", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.scheme-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), sections 6.2.2.11 and 6.3.5, read 2026-09-19. The guideline does not say how long in time is.", "confidence": "high" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the Scheme Operator uses its own redirect URLs so it can send the merchant status UNKNOWN if no bank confirmation arrives in time, redirecting the buyer to the shop, and that a bank confirmation arriving after that redirect is refused with HTTP 412." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:exc.outcome-unknown", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:021", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:033", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps:rule.vok-without-guarantee", "id": "rule.vok-without-guarantee", "rail": "eps", "class": "Rule", "name": "VOK where the contract is not guaranteed or the date is in the future", "statement": "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].", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "section 7.1.12 (overview of eps status codes); section 6.2.2.7", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "eps:role.debtor-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "eps:txn.eps-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7 (file listed 2026-03-25), sections 6.2.2.7 and 7.1.12, read 2026-09-19. The two sections leave open who writes VOK.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the status overview table gives OK under a guaranteed contract without a future option date, VOK where the contract is not guaranteed or a future date is set, and NOK on buyer termination or non-execution, while the same guideline says the debtor bank itself sends only OK or NOK." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps:src.adyen-eps", "id": "src.adyen-eps", "rail": "eps", "class": "RuleSource", "name": "Adyen Docs, EPS", "summary": "Adyen's documentation page for EPS: calls it a guaranteed payment method operated by Stuzza, Austria and EUR, refunds, partial refunds and multiple partial refunds supported, chargebacks not supported. A processor's own summary.", "publisher": "Adyen", "url": "https://docs.adyen.com/payment-methods/eps", "source_class": "secondary", "kind": "web_page", "edition": "live page as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The page as fetched on 2026-09-19; the feature table was read from the HTML (check and cross icons).", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created on 2026-09-19 for the eps rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "live page as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "eps:rule.processor-no-chargebacks", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.processor-refund-windows", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "eps:src.psa-eps-haendler-page", "id": "src.psa-eps-haendler-page", "rail": "eps", "class": "RuleSource", "name": "eps-Überweisung, Händler page and FAQ", "summary": "PSA's page for merchants (German): what eps offers a web shop, the merchant contract with the house bank or an acquirer, prices from the bank, the free test system, and a marketing description of the bank's execution guarantee.", "publisher": "PSA Payment Services Austria GmbH", "url": "https://eps-ueberweisung.at/de/haendler", "source_class": "public_primary", "kind": "web_page", "edition": "live page, undated, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The page as fetched on 2026-09-19, read as extracted text. No cookie banner was accepted.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created on 2026-09-19 for the eps rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "live page, undated, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "eps:rule.merchant-contract", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.no-cancel-after-ok", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "eps:src.psa-eps-implementation-guideline-2-7", "id": "src.psa-eps-implementation-guideline-2-7", "rail": "eps", "class": "RuleSource", "name": "eps e-payment standard, Standard Implementation Guideline, version 2.7", "summary": "PSA's English implementation guideline for the eps e-payment standard: the organisational prerequisites, the XML messages, the status values and the error and status reason code lists, the payment workflow through the Scheme Operator, eps4mobile, and the mapping to the SCT interbank message. PSA calls the standard open and public without licence fees; the download page lists no licence.", "publisher": "PSA Payment Services Austria GmbH", "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", "kind": "technical_standard", "edition": "version 2.7, cover dated March 2025, file listed on the PSA download page 2026-03-25", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The PDF itself (90 pages, 2,221,917 bytes, SHA-256 654a972e...4cbd7), downloaded from eps-ueberweisung.at and read in full on 2026-09-19. The document history in it stops at version 2.6.2.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created on 2026-09-19 for the eps rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "version 2.7, cover dated March 2025, file listed on the PSA download page 2026-03-25", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "eps:rail.eps", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "eps:exc.error-response", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:exc.not-completed", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:exc.outcome-unknown", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:role.buyer", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:role.creditor-bank", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:role.debtor-bank", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:role.merchant", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:role.scheme-operator", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.bank-executes-after-vitality-check", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.bank-legal-framework", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.buyer-authenticates-at-own-bank", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.consumer-rights-outside-eps", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.debtor-bank-decides-execution", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.debtor-bank-signs-confirmation", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.eps-fields-map-to-pacs008", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.eps4mobile-flows", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.error-in-synchronous-response", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.expiration-window", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.field-length-caps", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.funds-move-as-sepa-credit-transfer", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.guarantee-on-ok", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.merchant-confirms-confirmation", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.merchant-contract", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.merchant-offers-all-banks", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.no-cancel-after-ok", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.no-eps-return-or-recall", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.no-scheme-amount-limit", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.no-transfer-if-merchant-unreachable", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.nok-ends-payment-without-transfer", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.ok-only-after-authorisation-and-vitality-check", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.redirect-error-values", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.refund-as-new-sct", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.so-fraud-abort", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.so-only-error-013", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.so-routing-mandatory", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.so-timeouts-20-seconds", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.so-validates-initiation", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.status-request-42-days", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.status-values", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.three-confirmation-attempts", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.unknown-on-late-confirmation", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.vok-without-guarantee", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:txn.eps-payment", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "eps:src.psa-eps-privatkunden-page", "id": "src.psa-eps-privatkunden-page", "rail": "eps", "class": "RuleSource", "name": "eps-Überweisung, Privatkunden page and FAQ", "summary": "PSA's page for consumers (German): how a buyer pays through their own online banking, that no registration is needed, that bank data is not passed to third parties, that paying from abroad works wherever the account is reachable, and the count of web shops in Austria.", "publisher": "PSA Payment Services Austria GmbH", "url": "https://eps-ueberweisung.at/de/privatkunden", "source_class": "public_primary", "kind": "web_page", "edition": "live page, undated, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The page as fetched on 2026-09-19, read as extracted text.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created on 2026-09-19 for the eps rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "live page, undated, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "eps:rule.buyer-authenticates-at-own-bank", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.consumer-rights-outside-eps", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "eps:src.psa-eps-refundierung-1-0-1", "id": "src.psa-eps-refundierung-1-0-1", "rail": "eps", "class": "RuleSource", "name": "eps Refundierung, version 1.0.1", "summary": "PSA's German specification of eps refunds: the refund request and response, the checks the Scheme Operator runs, the refund error codes, and the SEPA credit transfer order the SO writes. The document still names STUZZA as maintainer.", "publisher": "PSA Payment Services Austria GmbH", "url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/16-eps-refundierung-dokumentation", "source_class": "authoritative_primary", "kind": "technical_standard", "edition": "version 1.0.1 dated 22 October 2018, file listed 2022-09-01", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The PDF itself (18 pages, 541,357 bytes, SHA-256 646f8921...f0104a), downloaded from eps-ueberweisung.at and read in full on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created on 2026-09-19 for the eps rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "version 1.0.1 dated 22 October 2018, file listed 2022-09-01", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "eps:exc.refund-refused", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:exc.refund", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:role.creditor-bank", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:role.merchant", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "eps:role.scheme-operator", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.no-eps-return-or-recall", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.refund-acceptance-not-guarantee", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.refund-answered-in-response", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.refund-as-new-sct", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.refund-cap-original-amount", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.refund-merchant-initiated-via-so", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.refund-needs-bank-agreement", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.refund-original-completed-within-13-months", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.refund-request-time-3-hours", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:txn.eps-refund", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "eps:src.psa-eservices-technisches-beiblatt-1-8", "id": "src.psa-eservices-technisches-beiblatt-1-8", "rail": "eps", "class": "RuleSource", "name": "EPS/EMS/EID Technisches Beiblatt, version 1.8", "summary": "PSA's German technical sheet for its eServices (eps, the eMS e-mandate and eID): clock tolerance, endpoint URLs per protocol version, connection and read timeouts, the valid expiration time window, and how long a status can be requested. Only its eps lines are used.", "publisher": "PSA Payment Services Austria GmbH", "url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/3-e-services-technisches-beiblatt", "source_class": "authoritative_primary", "kind": "technical_standard", "edition": "version 1.8, November 2025", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The PDF itself (7 pages, 183,712 bytes, SHA-256 2741043a...4100), downloaded from eps-ueberweisung.at and read in full on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created on 2026-09-19 for the eps rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "version 1.8, November 2025", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "eps:exc.outcome-unknown", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.expiration-window", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.initiation-clock-skew-3-minutes", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.so-timeouts-20-seconds", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.status-request-42-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "eps:src.stripe-eps-payments", "id": "src.stripe-eps-payments", "rail": "eps", "class": "RuleSource", "name": "Stripe Docs, EPS payments", "summary": "Stripe's documentation page for accepting EPS: customer-authenticated, EUR, no dispute support, refunds and partial refunds up to 180 days after the payment. A processor's own terms, not an eps rule.", "publisher": "Stripe", "url": "https://docs.stripe.com/payments/eps", "source_class": "secondary", "kind": "web_page", "edition": "live page as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The page as fetched on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created on 2026-09-19 for the eps rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "live page as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "eps:rule.processor-no-chargebacks", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "eps:rule.processor-refund-windows", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "eps:txn.eps-payment", "id": "txn.eps-payment", "rail": "eps", "class": "TransactionType", "name": "eps payment (eps-Überweisung)", "summary": "A credit transfer in euro from the buyer's account to the merchant's IBAN, initiated by the merchant through the Scheme Operator and authorised by the buyer in their online banking or banking app. The debtor bank executes it as a SEPA credit transfer; the IG maps its fields to the interbank pacs.008 message.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-implementation-guideline-2-7", "section": "sections 1.1, 6.2.1, 7.1.7, 9.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "eps Standard Implementation Guideline version 2.7, sections 1.1, 6.2.1, 7.1.7 and 9.1, read 2026-09-19. sec_code is null: eps has no entry class codes.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from PSA's eps documents as published on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the payment as a euro credit transfer initiated by the merchant through the Scheme Operator and authorised by the buyer, executed by the debtor bank as a SEPA credit transfer, with fields mapped to pacs.008." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:rule.bank-executes-after-vitality-check", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.buyer-authenticates-at-own-bank", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.consumer-rights-outside-eps", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.debtor-bank-decides-execution", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.debtor-bank-signs-confirmation", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.eps-fields-map-to-pacs008", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.eps4mobile-flows", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.error-in-synchronous-response", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.expiration-window", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.field-length-caps", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.funds-move-as-sepa-credit-transfer", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.guarantee-on-ok", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.initiation-clock-skew-3-minutes", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.merchant-confirms-confirmation", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.merchant-offers-all-banks", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.no-cancel-after-ok", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.no-eps-return-or-recall", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.no-scheme-amount-limit", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.no-transfer-if-merchant-unreachable", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.nok-ends-payment-without-transfer", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.ok-only-after-authorisation-and-vitality-check", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.processor-no-chargebacks", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.redirect-error-values", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.so-fraud-abort", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.so-only-error-013", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.so-routing-mandatory", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.so-validates-initiation", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.status-request-42-days", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.status-values", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.three-confirmation-attempts", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.unknown-on-late-confirmation", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.vok-without-guarantee", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps:txn.eps-refund", "id": "txn.eps-refund", "rail": "eps", "class": "TransactionType", "name": "eps refund", "summary": "A SEPA credit transfer order (pain.001) that the Scheme Operator writes, at the merchant's request, from a merchant IBAN registered at the SO to the buyer's account of an earlier completed eps payment, and hands to the merchant's bank to execute.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "eps:src.psa-eps-refundierung-1-0-1", "section": "sections 2.2, 7.1, 8.2, 8.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "eps Refundierung version 1.0.1, sections 2.2, 7.1, 8.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 on eps-ueberweisung.at that day; no later change identified.", "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 relevant, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "eps:src.psa-eps-refundierung-1-0-1", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms the refund as an SCT pain.001 order the Scheme Operator writes at the merchant's request from a registered merchant IBAN to the buyer's account of the earlier eps payment, handed to the merchant's bank to execute." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:rule.processor-refund-windows", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.refund-acceptance-not-guarantee", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.refund-answered-in-response", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.refund-as-new-sct", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.refund-cap-original-amount", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.refund-merchant-initiated-via-so", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.refund-needs-bank-agreement", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.refund-original-completed-within-13-months", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "eps:rule.refund-request-time-3-hours", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "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].", "rules": [ "eps:rule.buyer-authenticates-at-own-bank", "eps:rule.consumer-rights-outside-eps" ], "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.", "relations": [ { "type": "see_also", "to": "sepa-sct:consumer-law", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct-inst:consumer-law", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "eps:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps:src.psa-eps-implementation-guideline-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": "eps:src.psa-eps-privatkunden-page", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:refund", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "eps:rule.so-validates-initiation", "eps:rule.so-fraud-abort", "eps:rule.debtor-bank-decides-execution", "eps:rule.merchant-confirms-confirmation", "eps:rule.refund-needs-bank-agreement", "eps:rule.refund-acceptance-not-guarantee" ], "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.", "relations": [ { "type": "see_also", "to": "sepa-sct:decision-points", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "eps:participants", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps:src.psa-eps-implementation-guideline-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": "eps:src.psa-eps-refundierung-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:participants", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "eps:rule.ok-only-after-authorisation-and-vitality-check", "eps:rule.guarantee-on-ok", "eps:rule.vok-without-guarantee", "eps:rule.no-cancel-after-ok", "eps:rule.funds-move-as-sepa-credit-transfer" ], "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].", "relations": [ { "type": "see_also", "to": "sepa-sct:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct-inst:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "eps:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "eps:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "eps:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps:src.psa-eps-implementation-guideline-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:liability", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "eps:settlement", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "eps:rule.expiration-window", "eps:rule.so-timeouts-20-seconds", "eps:rule.initiation-clock-skew-3-minutes", "eps:rule.refund-request-time-3-hours", "eps:rule.status-request-42-days" ], "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.", "relations": [ { "type": "see_also", "to": "sepa-sct:hours", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct-inst:hours", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "eps:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps:src.psa-eps-implementation-guideline-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": "eps:src.psa-eservices-technisches-beiblatt-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": "eps:src.psa-eps-refundierung-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "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.", "rules": [ "eps:rule.guarantee-on-ok", "eps:rule.vok-without-guarantee", "eps:rule.three-confirmation-attempts", "eps:rule.refund-acceptance-not-guarantee", "eps:rule.merchant-contract", "eps:rule.bank-legal-framework" ], "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.", "relations": [ { "type": "see_also", "to": "sepa-sct:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct-inst:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "eps:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps:src.psa-eps-implementation-guideline-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": "eps:src.psa-eps-refundierung-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:finality", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "eps:rule.no-scheme-amount-limit", "eps:rule.field-length-caps", "eps:rule.refund-cap-original-amount" ], "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.", "relations": [ { "type": "see_also", "to": "sepa-sct:limits", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct-inst:limits", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "eps:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps:src.psa-eps-implementation-guideline-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": "eps:src.psa-eps-refundierung-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "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.", "rules": [ "eps:rule.status-values", "eps:rule.unknown-on-late-confirmation", "eps:rule.redirect-error-values", "eps:rule.merchant-confirms-confirmation", "eps:rule.debtor-bank-signs-confirmation", "eps:rule.error-in-synchronous-response", "eps:rule.so-only-error-013", "eps:rule.eps-fields-map-to-pacs008", "eps:rule.eps4mobile-flows" ], "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.", "relations": [ { "type": "see_also", "to": "sepa-sct:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "eps:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "eps:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps:src.psa-eps-implementation-guideline-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": "eps:src.psa-eps-refundierung-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:settlement", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "eps-error:rail.eps-error", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "eps-refund-error:rail.eps-refund-error", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:rail.eps-status-reason", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "eps:rule.so-routing-mandatory", "eps:rule.bank-legal-framework", "eps:rule.merchant-contract", "eps:rule.merchant-offers-all-banks", "eps:rule.buyer-authenticates-at-own-bank" ], "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].", "relations": [ { "type": "see_also", "to": "sepa-sct:participants", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "eps:decision-points", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps:src.psa-eps-implementation-guideline-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": "eps:src.psa-eps-privatkunden-page", "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": "eps:src.adyen-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:decision-points", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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].", "rules": [ "eps:rule.no-eps-return-or-recall", "eps:rule.no-cancel-after-ok", "eps:rule.refund-merchant-initiated-via-so", "eps:rule.funds-move-as-sepa-credit-transfer" ], "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.", "relations": [ { "type": "see_also", "to": "sepa-sct:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct-inst:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct:DUPL", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct:TECH", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct:FRAD", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct:CUST", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "eps:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps:src.psa-eps-implementation-guideline-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:finality", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "eps:rule.refund-merchant-initiated-via-so", "eps:rule.refund-needs-bank-agreement", "eps:rule.refund-original-completed-within-13-months", "eps:rule.refund-cap-original-amount", "eps:rule.refund-as-new-sct", "eps:rule.refund-acceptance-not-guarantee", "eps:rule.processor-refund-windows" ], "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].", "relations": [ { "type": "see_also", "to": "sepa-sct:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct-inst:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "eps:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "eps:consumer-law", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps:src.psa-eps-refundierung-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": "eps:src.stripe-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:consumer-law", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "eps:hours", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "eps:limits", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "eps:messages", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "eps:recall", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "eps:return", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "eps:rule.nok-ends-payment-without-transfer", "eps:rule.debtor-bank-decides-execution", "eps:rule.error-in-synchronous-response", "eps:rule.no-eps-return-or-recall", "eps:rule.processor-no-chargebacks" ], "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.", "relations": [ { "type": "see_also", "to": "sepa-sct:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct-inst:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct:AC04", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct:AC06", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct:AC01", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "eps:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps:src.psa-eps-implementation-guideline-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": "eps:src.stripe-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:messages", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "eps:refund", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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].", "rules": [ "eps:rule.so-routing-mandatory", "eps:rule.bank-executes-after-vitality-check", "eps:rule.no-transfer-if-merchant-unreachable", "eps:rule.funds-move-as-sepa-credit-transfer", "eps:rule.eps-fields-map-to-pacs008" ], "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.", "relations": [ { "type": "see_also", "to": "sepa-sct:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct-inst:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "eps:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "eps:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps:src.psa-eps-implementation-guideline-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps:finality", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps-error:rail.eps-error", "id": "rail.eps-error", "class": "Rail", "rail": "eps-error", "name": "eps Payment Messages", "governing_authority": "PSA Payment Services Austria GmbH", "country": "AT", "currency": "EUR", "operators": [ "PSA Payment Services Austria GmbH (eService Scheme Operator)" ], "record_label": "Error Codes", "brief": "docs/rails/eps.md", "scheme": "eps:rail.eps", "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" ], "relations": [ { "type": "sourced_from", "to": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "sections 4.10, 6.5, 7.1.4", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "eps:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "source_class": null, "effective_status_reason": null, "used_by": [] }, { "uid": "eps-error:src.psa-eps-implementation-guideline-2-7", "id": "src.psa-eps-implementation-guideline-2-7", "rail": "eps-error", "class": "RuleSource", "name": "eps e-payment standard, Standard Implementation Guideline, version 2.7", "summary": "PSA's English implementation guideline for the eps e-payment standard: the organisational prerequisites, the XML messages, the status values and the error and status reason code lists, the payment workflow through the Scheme Operator, eps4mobile, and the mapping to the SCT interbank message. PSA calls the standard open and public without licence fees; the download page lists no licence.", "publisher": "PSA Payment Services Austria GmbH", "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", "kind": "technical_standard", "edition": "version 2.7, cover dated March 2025, file listed on the PSA download page 2026-03-25", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The PDF itself (90 pages, 2,221,917 bytes, SHA-256 654a972e...4cbd7), downloaded from eps-ueberweisung.at and read in full on 2026-09-19. The document history in it stops at version 2.6.2.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created on 2026-09-19 for the eps rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "version 2.7, cover dated March 2025, file listed on the PSA download page 2026-03-25", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "eps-error:rail.eps-error", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps-error:002", "id": "002", "rail": "eps-error", "class": "ReasonCode", "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, "guidance": "After the URL is corrected; the refused initiation ended and nothing was debited." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "eps:txn.eps-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "eps:exc.error-response", "evidence": [ { "source": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "section 4.10 (general error table)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.scheme-operator", "evidence": [ { "source": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "section 4.10 (error table for messages from the SO)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.error-in-synchronous-response", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.field-length-caps", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps-error:src.psa-eps-implementation-guideline-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps-error:003", "id": "003", "rail": "eps-error", "class": "ReasonCode", "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, "guidance": "After the currency is corrected; nothing was debited." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "eps:txn.eps-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "eps:exc.error-response", "evidence": [ { "source": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "section 4.10 (general error table)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.debtor-bank", "evidence": [ { "source": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "sections 6.5 and 7.1.4 (error codes a debtor bank may send in epsp:BankResponseDetails)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.error-in-synchronous-response", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps-error:src.psa-eps-implementation-guideline-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps-error:004", "id": "004", "rail": "eps-error", "class": "ReasonCode", "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, "guidance": "Only after the credentials or the merchant's status are fixed; the same request draws the same error." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "eps:txn.eps-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "eps:exc.error-response", "evidence": [ { "source": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "section 4.10 (general error table)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.scheme-operator", "evidence": [ { "source": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "section 4.10 (error table for messages from the SO)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.debtor-bank", "evidence": [ { "source": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "sections 6.5 and 7.1.4 (error codes a debtor bank may send in epsp:BankResponseDetails)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.error-in-synchronous-response", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.so-validates-initiation", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps-error:src.psa-eps-implementation-guideline-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps-error:007", "id": "007", "rail": "eps-error", "class": "ReasonCode", "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, "guidance": "After the message is corrected; nothing was debited." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "eps:txn.eps-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "eps:exc.error-response", "evidence": [ { "source": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "section 4.10 (general error table)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.scheme-operator", "evidence": [ { "source": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "section 4.10 (error table for messages from the SO)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.debtor-bank", "evidence": [ { "source": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "sections 6.5 and 7.1.4 (error codes a debtor bank may send in epsp:BankResponseDetails)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.error-in-synchronous-response", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps-error:src.psa-eps-implementation-guideline-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps-error:008", "id": "008", "rail": "eps-error", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "eps:txn.eps-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "eps:exc.error-response", "evidence": [ { "source": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "section 4.10 (general error table)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.scheme-operator", "evidence": [ { "source": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "section 4.10 (error table for messages from the SO)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.debtor-bank", "evidence": [ { "source": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "sections 6.5 and 7.1.4 (error codes a debtor bank may send in epsp:BankResponseDetails)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.error-in-synchronous-response", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.so-timeouts-20-seconds", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps-error:src.psa-eps-implementation-guideline-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps-error:009", "id": "009", "rail": "eps-error", "class": "ReasonCode", "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, "guidance": "Later, unchanged; the fault is on the receiving side and nothing was debited." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "eps:txn.eps-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "eps:exc.error-response", "evidence": [ { "source": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "section 4.10 (general error table)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.scheme-operator", "evidence": [ { "source": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "section 4.10 (error table for messages from the SO)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.debtor-bank", "evidence": [ { "source": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "sections 6.5 and 7.1.4 (error codes a debtor bank may send in epsp:BankResponseDetails)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.error-in-synchronous-response", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps-error:src.psa-eps-implementation-guideline-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps-error:010", "id": "010", "rail": "eps-error", "class": "ReasonCode", "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, "guidance": "After the IBAN is corrected or registered; nothing was debited." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "eps:txn.eps-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "eps:exc.error-response", "evidence": [ { "source": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "section 4.10 (general error table)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.scheme-operator", "evidence": [ { "source": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "section 4.10 (error table for messages from the SO)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.debtor-bank", "evidence": [ { "source": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "sections 6.5 and 7.1.4 (error codes a debtor bank may send in epsp:BankResponseDetails)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.error-in-synchronous-response", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.so-validates-initiation", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps-error:src.psa-eps-implementation-guideline-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps-error:011", "id": "011", "rail": "eps-error", "class": "ReasonCode", "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, "guidance": "After the BIC is corrected; nothing was debited." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "eps:txn.eps-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "eps:exc.error-response", "evidence": [ { "source": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "section 4.10 (general error table)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.scheme-operator", "evidence": [ { "source": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "section 4.10 (error table for messages from the SO)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.debtor-bank", "evidence": [ { "source": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "sections 6.5 and 7.1.4 (error codes a debtor bank may send in epsp:BankResponseDetails)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.error-in-synchronous-response", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps-error:src.psa-eps-implementation-guideline-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps-error:012", "id": "012", "rail": "eps-error", "class": "ReasonCode", "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, "guidance": "After the time is corrected; nothing was debited." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "eps:txn.eps-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "eps:exc.error-response", "evidence": [ { "source": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "section 4.10 (general error table)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.scheme-operator", "evidence": [ { "source": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "section 4.10 (error table for messages from the SO)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.debtor-bank", "evidence": [ { "source": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "sections 6.5 and 7.1.4 (error codes a debtor bank may send in epsp:BankResponseDetails)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.error-in-synchronous-response", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.expiration-window", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.so-validates-initiation", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "eps-refund-error:012", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps-error:src.psa-eps-implementation-guideline-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps-refund-error:012", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps-error:013", "id": "013", "rail": "eps-error", "class": "ReasonCode", "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, "guidance": "Not with the same parties and accounts: the refusal rests on what the payment is, not on a passing fault." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "eps:txn.eps-payment" ], "excludes": [], "text": "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].", "relations": [ { "type": "raised_in", "to": "eps:exc.error-response", "evidence": [ { "source": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "section 4.10 (general error table)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.scheme-operator", "evidence": [ { "source": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "sections 6.5 and 7.1.4 (013 reserved to the SO)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.error-in-synchronous-response", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.so-only-error-013", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "eps-refund-error:013", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps-error:src.psa-eps-implementation-guideline-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps-refund-error:013", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps-error:014", "id": "014", "rail": "eps-error", "class": "ReasonCode", "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, "guidance": "Later; the bank side was unreachable and nothing was debited." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "eps:txn.eps-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "eps:exc.error-response", "evidence": [ { "source": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "section 4.10 (general error table)" } ], "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.scheme-operator", "evidence": [ { "source": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "section 4.10 (error table for messages from the SO)" } ], "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.debtor-bank", "evidence": [ { "source": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "sections 6.5 and 7.1.4 (error codes a debtor bank may send in epsp:BankResponseDetails)" } ], "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.error-in-synchronous-response", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.so-timeouts-20-seconds", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "eps-error:015", "id": "015", "rail": "eps-error", "class": "ReasonCode", "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, "guidance": "After the bank selection is corrected; nothing was debited." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "eps:txn.eps-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "eps:exc.error-response", "evidence": [ { "source": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "section 4.10 (general error table)" } ], "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.scheme-operator", "evidence": [ { "source": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "section 4.10 (error table for messages from the SO)" } ], "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.debtor-bank", "evidence": [ { "source": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "sections 6.5 and 7.1.4 (error codes a debtor bank may send in epsp:BankResponseDetails)" } ], "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.error-in-synchronous-response", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.merchant-offers-all-banks", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "eps-refund-error:015", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "eps-refund-error:015", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps-error:020", "id": "020", "rail": "eps-error", "class": "ReasonCode", "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, "guidance": "Only with the correct TransactionId; a details request for a confirmed transaction keeps drawing 020." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "eps:txn.eps-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "eps:exc.error-response", "evidence": [ { "source": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "section 4.10 (general error table)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.scheme-operator", "evidence": [ { "source": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "section 4.10 (error table for messages from the SO)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.error-in-synchronous-response", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.status-request-42-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "eps-refund-error:020", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps-error:src.psa-eps-implementation-guideline-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps-refund-error:020", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps-error:021", "id": "021", "rail": "eps-error", "class": "ReasonCode", "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, "guidance": "Later: ask again once the payment has had time to finish." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "eps:txn.eps-payment" ], "excludes": [], "text": "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).", "relations": [ { "type": "raised_in", "to": "eps:exc.error-response", "evidence": [ { "source": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "section 4.10 (general error table)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.scheme-operator", "evidence": [ { "source": "eps-error:src.psa-eps-implementation-guideline-2-7", "section": "section 4.10 (error table for messages from the SO)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.error-in-synchronous-response", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.status-request-42-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "eps-status-reason:021", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "eps-refund-error:021", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps-error:src.psa-eps-implementation-guideline-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps-refund-error:021", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:021", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps-refund-error:rail.eps-refund-error", "id": "rail.eps-refund-error", "class": "Rail", "rail": "eps-refund-error", "name": "eps Refunds", "governing_authority": "PSA Payment Services Austria GmbH", "country": "AT", "currency": "EUR", "operators": [ "PSA Payment Services Austria GmbH (eService Scheme Operator)" ], "record_label": "Error Codes", "brief": "docs/rails/eps.md", "scheme": "eps:rail.eps", "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" ], "relations": [ { "type": "sourced_from", "to": "eps-refund-error:src.psa-eps-refundierung-1-0-1", "section": "sections 4.6, 7.2", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "eps:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "source_class": null, "effective_status_reason": null, "used_by": [] }, { "uid": "eps-refund-error:src.psa-eps-refundierung-1-0-1", "id": "src.psa-eps-refundierung-1-0-1", "rail": "eps-refund-error", "class": "RuleSource", "name": "eps Refundierung, version 1.0.1", "summary": "PSA's German specification of eps refunds: the refund request and response, the checks the Scheme Operator runs, the refund error codes, and the SEPA credit transfer order the SO writes. The document still names STUZZA as maintainer.", "publisher": "PSA Payment Services Austria GmbH", "url": "https://eps-ueberweisung.at/de/download/eps-ueberweisung-dokumentation/send/2-eps-ueberweisung-dokumentation/16-eps-refundierung-dokumentation", "source_class": "authoritative_primary", "kind": "technical_standard", "edition": "version 1.0.1 dated 22 October 2018, file listed 2022-09-01", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The PDF itself (18 pages, 541,357 bytes, SHA-256 646f8921...f0104a), downloaded from eps-ueberweisung.at and read in full on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created on 2026-09-19 for the eps rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "version 1.0.1 dated 22 October 2018, file listed 2022-09-01", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "eps-refund-error:rail.eps-refund-error", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps-refund-error:004", "id": "004", "rail": "eps-refund-error", "class": "ReasonCode", "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, "guidance": "After the credentials are fixed; no payment order was created." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "eps:txn.eps-refund" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "eps:exc.refund-refused", "evidence": [ { "source": "eps-refund-error:src.psa-eps-refundierung-1-0-1", "section": "section 4.6 (error codes in epsr:EpsRefundResponse)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.scheme-operator", "evidence": [ { "source": "eps-refund-error:src.psa-eps-refundierung-1-0-1", "section": "sections 4.6, 7.2" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.refund-answered-in-response", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.refund-merchant-initiated-via-so", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps-refund-error:src.psa-eps-refundierung-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps-refund-error:007", "id": "007", "rail": "eps-refund-error", "class": "ReasonCode", "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, "guidance": "After the message is corrected; no payment order was created." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "eps:txn.eps-refund" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "eps:exc.refund-refused", "evidence": [ { "source": "eps-refund-error:src.psa-eps-refundierung-1-0-1", "section": "section 4.6 (error codes in epsr:EpsRefundResponse)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.scheme-operator", "evidence": [ { "source": "eps-refund-error:src.psa-eps-refundierung-1-0-1", "section": "sections 4.6, 7.2" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.refund-answered-in-response", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps-refund-error:src.psa-eps-refundierung-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps-refund-error:009", "id": "009", "rail": "eps-refund-error", "class": "ReasonCode", "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, "guidance": "Later, unchanged; no payment order was created." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "eps:txn.eps-refund" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "eps:exc.refund-refused", "evidence": [ { "source": "eps-refund-error:src.psa-eps-refundierung-1-0-1", "section": "section 4.6 (error codes in epsr:EpsRefundResponse)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.scheme-operator", "evidence": [ { "source": "eps-refund-error:src.psa-eps-refundierung-1-0-1", "section": "sections 4.6, 7.2" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.refund-answered-in-response", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps-refund-error:src.psa-eps-refundierung-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps-refund-error:010", "id": "010", "rail": "eps-refund-error", "class": "ReasonCode", "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, "guidance": "After a registered IBAN is used; no payment order was created." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "eps:txn.eps-refund" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "eps:exc.refund-refused", "evidence": [ { "source": "eps-refund-error:src.psa-eps-refundierung-1-0-1", "section": "section 4.6 (error codes in epsr:EpsRefundResponse)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.scheme-operator", "evidence": [ { "source": "eps-refund-error:src.psa-eps-refundierung-1-0-1", "section": "sections 4.6, 7.2" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.refund-answered-in-response", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.refund-needs-bank-agreement", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps-refund-error:src.psa-eps-refundierung-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps-refund-error:011", "id": "011", "rail": "eps-refund-error", "class": "ReasonCode", "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, "guidance": "Only after the merchant's bank routing is set up at the SO." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "eps:txn.eps-refund" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "eps:exc.refund-refused", "evidence": [ { "source": "eps-refund-error:src.psa-eps-refundierung-1-0-1", "section": "section 4.6 (error codes in epsr:EpsRefundResponse)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.scheme-operator", "evidence": [ { "source": "eps-refund-error:src.psa-eps-refundierung-1-0-1", "section": "sections 4.6, 7.2" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.refund-answered-in-response", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.refund-needs-bank-agreement", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps-refund-error:src.psa-eps-refundierung-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps-refund-error:012", "id": "012", "rail": "eps-refund-error", "class": "ReasonCode", "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, "guidance": "With a fresh creation time; no payment order was created." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "eps:txn.eps-refund" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "eps:exc.refund-refused", "evidence": [ { "source": "eps-refund-error:src.psa-eps-refundierung-1-0-1", "section": "section 4.6 (error codes in epsr:EpsRefundResponse)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.scheme-operator", "evidence": [ { "source": "eps-refund-error:src.psa-eps-refundierung-1-0-1", "section": "sections 4.6, 7.2" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.refund-answered-in-response", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.refund-request-time-3-hours", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "eps-error:012", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps-refund-error:src.psa-eps-refundierung-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps-error:012", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps-refund-error:013", "id": "013", "rail": "eps-refund-error", "class": "ReasonCode", "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, "guidance": "Not with the same accounts: the refusal rests on what the order is, not on a passing fault." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "eps:txn.eps-refund" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "eps:exc.refund-refused", "evidence": [ { "source": "eps-refund-error:src.psa-eps-refundierung-1-0-1", "section": "section 4.6 (error codes in epsr:EpsRefundResponse)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.scheme-operator", "evidence": [ { "source": "eps-refund-error:src.psa-eps-refundierung-1-0-1", "section": "sections 4.6, 7.2" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.refund-answered-in-response", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "eps-error:013", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps-refund-error:src.psa-eps-refundierung-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps-error:013", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps-refund-error:015", "id": "015", "rail": "eps-refund-error", "class": "ReasonCode", "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, "guidance": "Only after the merchant's bank has completed its set-up; no payment order was created." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "eps:txn.eps-refund" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "eps:exc.refund-refused", "evidence": [ { "source": "eps-refund-error:src.psa-eps-refundierung-1-0-1", "section": "section 4.6 (error codes in epsr:EpsRefundResponse)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.scheme-operator", "evidence": [ { "source": "eps-refund-error:src.psa-eps-refundierung-1-0-1", "section": "sections 4.6, 7.2" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.refund-answered-in-response", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.refund-needs-bank-agreement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "eps-error:015", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps-refund-error:src.psa-eps-refundierung-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps-error:015", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps-refund-error:020", "id": "020", "rail": "eps-refund-error", "class": "ReasonCode", "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, "guidance": "With the correct TransactionId; no payment order was created." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "eps:txn.eps-refund" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "eps:exc.refund-refused", "evidence": [ { "source": "eps-refund-error:src.psa-eps-refundierung-1-0-1", "section": "section 4.6 (error codes in epsr:EpsRefundResponse)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.scheme-operator", "evidence": [ { "source": "eps-refund-error:src.psa-eps-refundierung-1-0-1", "section": "sections 4.6, 7.2" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.refund-answered-in-response", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.refund-merchant-initiated-via-so", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "eps-error:020", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps-refund-error:src.psa-eps-refundierung-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps-error:020", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps-refund-error:021", "id": "021", "rail": "eps-refund-error", "class": "ReasonCode", "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, "guidance": "Only once the original payment has completed; a payment that ended NOK moved no money and needs no refund." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "eps:txn.eps-refund" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "eps:exc.refund-refused", "evidence": [ { "source": "eps-refund-error:src.psa-eps-refundierung-1-0-1", "section": "section 4.6 (error codes in epsr:EpsRefundResponse)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.scheme-operator", "evidence": [ { "source": "eps-refund-error:src.psa-eps-refundierung-1-0-1", "section": "sections 4.6, 7.2" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.refund-answered-in-response", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.refund-original-completed-within-13-months", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "eps-error:021", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "eps-status-reason:021", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps-refund-error:src.psa-eps-refundierung-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps-error:021", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "eps-status-reason:021", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps-refund-error:022", "id": "022", "rail": "eps-refund-error", "class": "ReasonCode", "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, "guidance": "With an amount that keeps the refund total within the original payment." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "eps:txn.eps-refund" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "eps:exc.refund-refused", "evidence": [ { "source": "eps-refund-error:src.psa-eps-refundierung-1-0-1", "section": "section 4.6 (error codes in epsr:EpsRefundResponse)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.scheme-operator", "evidence": [ { "source": "eps-refund-error:src.psa-eps-refundierung-1-0-1", "section": "sections 4.6, 7.2" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.refund-answered-in-response", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.refund-cap-original-amount", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps-refund-error:src.psa-eps-refundierung-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps-status-reason:rail.eps-status-reason", "id": "rail.eps-status-reason", "class": "Rail", "rail": "eps-status-reason", "name": "eps Payment Confirmations", "governing_authority": "PSA Payment Services Austria GmbH", "country": "AT", "currency": "EUR", "operators": [ "PSA Payment Services Austria GmbH (eService Scheme Operator)" ], "record_label": "Status Reasons", "brief": "docs/rails/eps.md", "scheme": "eps:rail.eps", "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" ], "relations": [ { "type": "sourced_from", "to": "eps-status-reason:src.psa-eps-implementation-guideline-2-7", "section": "section 6.2.2.8", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "eps:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "source_class": null, "effective_status_reason": null, "used_by": [] }, { "uid": "eps-status-reason:src.psa-eps-implementation-guideline-2-7", "id": "src.psa-eps-implementation-guideline-2-7", "rail": "eps-status-reason", "class": "RuleSource", "name": "eps e-payment standard, Standard Implementation Guideline, version 2.7", "summary": "PSA's English implementation guideline for the eps e-payment standard: the organisational prerequisites, the XML messages, the status values and the error and status reason code lists, the payment workflow through the Scheme Operator, eps4mobile, and the mapping to the SCT interbank message. PSA calls the standard open and public without licence fees; the download page lists no licence.", "publisher": "PSA Payment Services Austria GmbH", "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", "kind": "technical_standard", "edition": "version 2.7, cover dated March 2025, file listed on the PSA download page 2026-03-25", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The PDF itself (90 pages, 2,221,917 bytes, SHA-256 654a972e...4cbd7), downloaded from eps-ueberweisung.at and read in full on 2026-09-19. The document history in it stops at version 2.6.2.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created on 2026-09-19 for the eps rail. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "version 2.7, cover dated March 2025, file listed on the PSA download page 2026-03-25", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "eps-status-reason:rail.eps-status-reason", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps-status-reason:021", "id": "021", "rail": "eps-status-reason", "class": "ReasonCode", "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, "guidance": "Not yet: a second payment could charge the buyer twice while this one may still complete. Check the status first." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "eps:txn.eps-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "eps:exc.outcome-unknown", "note": "[Inference] The guideline ties StatusReason to a declined payment and does not say which status this reason travels with; an open or unknown outcome fits it better than a decline.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.scheme-operator", "note": "[Inference] The Scheme Operator is the party that reports an unfinished payment; the guideline does not say who writes this reason.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.unknown-on-late-confirmation", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.status-request-42-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "eps-error:021", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "eps-refund-error:021", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps-status-reason:src.psa-eps-implementation-guideline-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "eps-error:021", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "eps-refund-error:021", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "eps-status-reason:030", "id": "030", "rail": "eps-status-reason", "class": "ReasonCode", "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, "guidance": "The buyer may start a new eps payment; nothing was debited." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "eps:txn.eps-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "eps:exc.not-completed", "evidence": [ { "source": "eps-status-reason:src.psa-eps-implementation-guideline-2-7", "section": "section 6.2.2.8 (eps:StatusReason ReasonCode table)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.debtor-bank", "note": "[Inference] Section 7.1.7 has the debtor bank send NOK when the buyer cancels; that this reason code goes with it is Orca's reading.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.expiration-window", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.debtor-bank-decides-execution", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps-status-reason:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms StatusReason 030 as a transaction cancelled by the customer." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps-status-reason:031", "id": "031", "rail": "eps-status-reason", "class": "ReasonCode", "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, "guidance": "A new initiation, once the NOK is in hand; with NOK nothing was debited." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "eps:txn.eps-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "eps:exc.not-completed", "evidence": [ { "source": "eps-status-reason:src.psa-eps-implementation-guideline-2-7", "section": "section 6.2.2.8 (eps:StatusReason ReasonCode table)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.debtor-bank", "note": "[Inference] The guideline does not say who writes this reason; both the debtor bank, which writes every NOK, and the Scheme Operator could, so both are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.scheme-operator", "note": "[Inference] The guideline does not say who writes this reason; both the debtor bank, which writes every NOK, and the Scheme Operator could, so both are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.expiration-window", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.so-timeouts-20-seconds", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps-status-reason:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms StatusReason 031 as a transaction timeout occurring after initiation." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps-status-reason:032", "id": "032", "rail": "eps-status-reason", "class": "ReasonCode", "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, "guidance": "Once the NOK status is confirmed; with NOK nothing was debited. If the status was UNKNOWN, check it first." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "eps:txn.eps-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "eps:exc.not-completed", "evidence": [ { "source": "eps-status-reason:src.psa-eps-implementation-guideline-2-7", "section": "section 6.2.2.8 (eps:StatusReason ReasonCode table)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.debtor-bank", "note": "[Inference] The guideline does not say who writes this reason; both the debtor bank, which writes every NOK, and the Scheme Operator could, so both are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.scheme-operator", "note": "[Inference] The guideline does not say who writes this reason; both the debtor bank, which writes every NOK, and the Scheme Operator could, so both are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.expiration-window", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.no-transfer-if-merchant-unreachable", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.so-timeouts-20-seconds", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps-status-reason:src.psa-eps-implementation-guideline-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps-status-reason:033", "id": "033", "rail": "eps-status-reason", "class": "ReasonCode", "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, "guidance": "Not until the status is known: the transfer may have been executed." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "eps:txn.eps-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "eps:exc.outcome-unknown", "note": "[Inference] The guideline ties StatusReason to a declined payment and does not say which status this reason travels with; an open or unknown outcome fits it better than a decline.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.scheme-operator", "note": "[Inference] The Scheme Operator sits in the redirect path and writes UNKNOWN when the confirmation is missing; the guideline does not say who writes this reason.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.unknown-on-late-confirmation", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.status-request-42-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps-status-reason:src.psa-eps-implementation-guideline-2-7", "checked_on": "2026-09-19", "checked_by": "validator-2026-09-19", "notes": "Confirms StatusReason 033 as a redirect without a payment confirmation." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps-status-reason:110", "id": "110", "rail": "eps-status-reason", "class": "ReasonCode", "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, "guidance": "Only once the buyer has cleared it with their bank; repeating at once will likely fail again. Nothing was debited." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "eps:txn.eps-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "eps:exc.not-completed", "evidence": [ { "source": "eps-status-reason:src.psa-eps-implementation-guideline-2-7", "section": "section 6.2.2.8 (eps:StatusReason ReasonCode table)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.debtor-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.expiration-window", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.debtor-bank-decides-execution", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps-status-reason:src.psa-eps-implementation-guideline-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps-status-reason:115", "id": "115", "rail": "eps-status-reason", "class": "ReasonCode", "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, "guidance": "Not automatically: the payment was stopped on fraud grounds, and a repeat may be stopped again." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "eps:txn.eps-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "eps:exc.not-completed", "evidence": [ { "source": "eps-status-reason:src.psa-eps-implementation-guideline-2-7", "section": "section 6.2.2.8 (eps:StatusReason ReasonCode table)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.scheme-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.so-fraud-abort", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps-status-reason:src.psa-eps-implementation-guideline-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps-status-reason:120", "id": "120", "rail": "eps-status-reason", "class": "ReasonCode", "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, "guidance": "Later; with NOK nothing was debited." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "eps:txn.eps-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "eps:exc.not-completed", "evidence": [ { "source": "eps-status-reason:src.psa-eps-implementation-guideline-2-7", "section": "section 6.2.2.8 (eps:StatusReason ReasonCode table)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.debtor-bank", "note": "[Inference] The guideline does not say who writes this reason; both the debtor bank, which writes every NOK, and the Scheme Operator could, so both are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.scheme-operator", "note": "[Inference] The guideline does not say who writes this reason; both the debtor bank, which writes every NOK, and the Scheme Operator could, so both are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.expiration-window", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps-status-reason:src.psa-eps-implementation-guideline-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps-status-reason:121", "id": "121", "rail": "eps-status-reason", "class": "ReasonCode", "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, "guidance": "After the merchant side is fixed; with NOK nothing was debited." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "eps:txn.eps-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "eps:exc.not-completed", "evidence": [ { "source": "eps-status-reason:src.psa-eps-implementation-guideline-2-7", "section": "section 6.2.2.8 (eps:StatusReason ReasonCode table)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.debtor-bank", "note": "[Inference] The guideline does not say who writes this reason; both the debtor bank, which writes every NOK, and the Scheme Operator could, so both are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.scheme-operator", "note": "[Inference] The guideline does not say who writes this reason; both the debtor bank, which writes every NOK, and the Scheme Operator could, so both are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.expiration-window", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.no-transfer-if-merchant-unreachable", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.so-timeouts-20-seconds", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps-status-reason:src.psa-eps-implementation-guideline-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps-status-reason:122", "id": "122", "rail": "eps-status-reason", "class": "ReasonCode", "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, "guidance": "After the signature fault is fixed; with NOK nothing was debited." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "eps:txn.eps-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "eps:exc.not-completed", "evidence": [ { "source": "eps-status-reason:src.psa-eps-implementation-guideline-2-7", "section": "section 6.2.2.8 (eps:StatusReason ReasonCode table)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.debtor-bank", "note": "[Inference] The guideline does not say who writes this reason; both the debtor bank, which writes every NOK, and the Scheme Operator could, so both are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.scheme-operator", "note": "[Inference] The guideline does not say who writes this reason; both the debtor bank, which writes every NOK, and the Scheme Operator could, so both are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.expiration-window", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.debtor-bank-signs-confirmation", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps-status-reason:src.psa-eps-implementation-guideline-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "eps-status-reason:123", "id": "123", "rail": "eps-status-reason", "class": "ReasonCode", "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, "guidance": "Not until the true outcome is established: a new payment could charge the buyer twice." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "eps:txn.eps-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "eps:exc.not-completed", "evidence": [ { "source": "eps-status-reason:src.psa-eps-implementation-guideline-2-7", "section": "section 6.2.2.8 (eps:StatusReason ReasonCode table)" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "eps:role.scheme-operator", "note": "[Inference] Only the Scheme Operator sees every confirmation for a payment, so it is the likely writer; the guideline does not say.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.expiration-window", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "eps:rule.debtor-bank-signs-confirmation", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "eps-status-reason:src.psa-eps-implementation-guideline-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "google-pay:rail.google-pay", "id": "rail.google-pay", "class": "Rail", "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", "operators": [ "Google LLC, which offers the Google Pay API to merchants under the Google Pay API Terms of Service effective 2021-03-01; the Google entity that provides the consumer wallet in each country was not read" ], "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" ], "relations": [ { "type": "sourced_from", "to": "google-pay:src.google-pay-api-tos", "section": "sections 1 to 7", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "google-pay:src.acceptable-use-policy", "section": "whole page", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "google-pay:src.payment-data-cryptography", "section": "payment method token structure and eciIndicator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:participants", "note": "The payment is a card payment; the Visa facts hold the network layer.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:participants", "note": "The payment is a card payment; the Mastercard facts hold the network layer.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "apple-pay:rail.apple-pay", "note": "The other pass-through wallet in the corpus, under the same brief.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "used_by": [ { "from": "apple-pay:rail.apple-pay", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "google-pay:exc.api-call-rejected", "id": "exc.api-call-rejected", "rail": "google-pay", "class": "Exception", "name": "The Google Pay API rejects the call", "summary": "A Google Pay API method rejects its promise and returns a PaymentsError instead of payment data. The four status codes cover a Google user who cannot supply payment information, a badly formatted parameter, a site without the right permission or with the wrong merchant identifier, and a general server error.", "money_moves": false, "outcome": "No payment data is returned and no payment happens. Three of the four codes are the merchant's or Google's own problem rather than the buyer's, and the developer-facing statusMessage is what says which. These are not payment outcomes and there is no reason code list on this rail.", "relations": [ { "type": "initiated_by", "to": "google-pay:role.google", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "google-pay:role.google", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "google-pay:rule.api-status-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "google-pay:src.web-error-objects", "section": "PaymentsError; status codes", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Error objects reference, read in full 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2025-02-10", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the last-updated date the page prints, which dates the page and not the values; they may be older [Unverified].", "source_edition": "Google Pay API for web, error objects reference, last updated 2025-02-10 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": "google-pay:src.web-error-objects", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the four status codes a rejected Google Pay API call returns." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "google-pay:rule.api-status-codes", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "google-pay:exc.google-corrective-action", "id": "exc.google-corrective-action", "rail": "google-pay", "class": "Exception", "name": "Google takes corrective action against a transaction or a partner", "summary": "Google believes or suspects that a partner or a transaction breaks the acceptable use policy or is otherwise illegal or unsuitable, or decides for any reason it deems prudent to act. The policy gives Google corrective action, disabling a transaction and disabling a partner account, and Google may also report illegal activity to the authorities.", "money_moves": false, "outcome": "The transaction or the partner account stops working. The policy sets no notice, no procedure and no review, and none was found on the pages read [Unverified]. Separately, under the terms, Google may require a merchant to disengage from a platform provider that contributed to a breach or other harm.", "relations": [ { "type": "initiated_by", "to": "google-pay:role.google", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "google-pay:role.google", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "google-pay:rule.google-may-take-corrective-action", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "google-pay:rule.restricted-products-and-services", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "google-pay:src.acceptable-use-policy", "section": "opening paragraphs", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "google-pay:src.google-pay-api-tos", "section": "section 3, second paragraph", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Google Pay and Wallet APIs Acceptable Use Policy; Google Pay API Terms of Service section 3; read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "Unknown: the effective date the policy states is not a real calendar date", "effective_to": null, "effective_note": "Drafted 2026-09-20. The policy states it is effective on April 31, 2025, a date that does not exist, so no effective date can be recorded [Unverified]. The policy says Google may expand or edit it at any time.", "source_edition": "Google Pay and Wallet APIs Acceptable Use Policy, the page states it is effective on April 31, 2025, a date that does not exist; 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": "google-pay:src.acceptable-use-policy", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms Google's reserved right to take corrective action, disable a transaction or partner account, and report illegal activity." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "google-pay:rule.google-may-take-corrective-action", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.no-staged-wallet-behind-google-pay", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.restricted-products-and-services", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "google-pay:exc.payload-rejected", "id": "exc.payload-rejected", "rail": "google-pay", "class": "Exception", "name": "Merchant rejects the payment payload", "summary": "The merchant or its gateway consumes the encrypted payload and a check fails: the intermediate signing key's signature does not verify against a non-expired root signing key, the intermediate key has expired, the payload signature does not verify, or the decrypted message is past its messageExpiration.", "money_moves": false, "outcome": "The merchant does not charge the payment method, so no card payment is presented. Google's pages say to reject an expired message and set out the verification order, but they do not say what the merchant tells the buyer or Google, and no such message was found [Unverified].", "relations": [ { "type": "initiated_by", "to": "google-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "google-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "google-pay:rule.payload-verification-steps", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "google-pay:rule.message-expiration", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "google-pay:src.payment-data-cryptography", "section": "steps for consuming the payload; encrypted message, messageExpiration", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "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. The date is the last-updated date the page prints, which dates the page and not the rule; the field or behaviour may be older [Unverified].", "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": "google-pay:src.payment-data-cryptography", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the payload verification steps whose failure means an intermediate key signature, an expired key, a payload signature or an expired message is rejected." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "google-pay:rule.message-expiration", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.payload-verification-steps", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "google-pay:role.card-acquiring-bank", "id": "role.card-acquiring-bank", "rail": "google-pay", "class": "Role", "name": "Card acquiring bank", "summary": "The bank the merchant must contract with to process card transactions. The terms make the merchant solely responsible for establishing that agreement, for all fees, charges and expenses it brings, and for complying with it and with any applicable payment network rules. Google has no part in it. The merchant's own use of End User personal information must also comply with that agreement.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "google-pay:src.google-pay-api-tos", "section": "sections 1 and 5(a)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "google-pay:src.sca-guide", "section": "transactionInfo.countryCode", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Google Pay API Terms of Service sections 1 and 5(a); SCA and Google Pay API; read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2021-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the effective date the terms state. Whether a later edition exists was not checked; the terms host disallows robots, so a person re-reads the page each quarter.", "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": "google-pay:src.google-pay-api-tos", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the merchant alone is responsible for its card acquiring agreement, for its fees, and for complying with that agreement and applicable payment network rules." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "google-pay:rule.merchant-needs-its-own-acquiring-agreement", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "google-pay:role.card-issuer", "id": "role.card-issuer", "rail": "google-pay", "class": "Role", "name": "Card issuer", "summary": "The institution that issued the card the End User saved to their Google Account or provisioned as an Android device token. It performs the identification and verification that assuranceDetails reports, it is one of the two liable parties in Google's ECI table, and it decides the authorisation. A user disputing a charge is sent to it, or to their card provider. Nothing on the pages read describes Google's arrangements with issuers.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "google-pay:src.web-response-objects", "section": "AssuranceDetailsSpecifications", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "google-pay:src.payment-data-cryptography", "section": "eciIndicator table", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "google-pay:src.help-dispute-7644016", "section": "step 4", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Response objects reference; payment data cryptography; Google Pay Help 7644016; read 2026-09-20. That the issuer decides the authorisation follows from the terms saying Google's enablement is not authorisation [Inference].", "confidence": "medium" }, "currency": { "effective_since": "2026-08-24", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the last-updated date the page prints, which dates the page and not the rule; the field or behaviour may be older [Unverified].", "source_edition": "Google Pay API for web, response objects reference, last updated 2026-08-24 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": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "google-pay:role.card-network", "id": "role.card-network", "rail": "google-pay", "class": "Role", "name": "Card network", "summary": "The network the card runs on. A merchant declares which networks it accepts, and Google's pages name AMEX, DISCOVER, INTERAC, JCB, MASTERCARD and VISA, with a separate list for tokenised Brazilian combo cards. The network may supply the eciIndicator for an authenticated device-token transaction, and JCB and Discover do not support CRYPTOGRAM_3DS because they do not support device account numbers. The network's rulebook, not Google's terms, governs authorisation, clearing, settlement, disputes and liability; Orca holds those rules in the visa and mastercard rails.", "kind": "operator", "relations": [ { "type": "sourced_from", "to": "google-pay:src.web-request-objects", "section": "CardParameters, allowedCardNetworks and the allowedAuthMethods note", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "google-pay:src.payment-data-cryptography", "section": "eciIndicator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:participants", "note": "Visa's own rules for the network layer.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:participants", "note": "Mastercard's own rules for the network layer.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Request objects reference; payment data cryptography; read 2026-09-20. No Visa or Mastercard document was read for this rail; what the network rules say is held in the visa and mastercard rails and linked, not restated.", "confidence": "high" }, "currency": { "effective_since": "2026-09-17", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the last-updated date the page prints, which dates the page and not the rule; the field or behaviour may be older [Unverified].", "source_edition": "Google Pay API for web, request objects reference, last updated 2026-09-17 UTC as the page states, read 2026-09-20 from the copy saved that day", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "google-pay:src.web-request-objects", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the card networks a merchant may declare support for and that JCB and Discover do not support CRYPTOGRAM_3DS." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "google-pay:role.cardholder", "id": "role.cardholder", "rail": "google-pay", "class": "Role", "name": "End user (the cardholder)", "summary": "The person who buys from the merchant and pays with a card held in their Google Account or as an Android device token. Google's terms call this party the End User and put the sale solely between the merchant and them. Google is not responsible for an End User's acts, including not completing a transaction, and a user with a suspected scam or fraudulent charge is told to go to their bank or card provider.", "kind": "party", "relations": [ { "type": "sourced_from", "to": "google-pay:src.google-pay-api-tos", "section": "section 1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "google-pay:src.help-dispute-7644016", "section": "step 4", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Google Pay API Terms of Service section 1; Google Pay Help 7644016; read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2021-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the effective date the terms state. Whether a later edition exists was not checked; the terms host disallows robots, so a person re-reads the page each quarter.", "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": "google-pay:src.google-pay-api-tos", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the End User buys from the merchant, that the sale is solely between them, and that Google is not responsible for the End User's acts." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "google-pay:rule.help-page-sends-the-user-to-the-bank", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "google-pay:role.google", "id": "role.google", "rail": "google-pay", "class": "Role", "name": "Google LLC (the wallet operator)", "summary": "The party that offers the Google Pay API to merchants and shares the payment credential. Google is not a party to the sale, does not promise that a transaction will be authorised or that it will not be charged back, and is not a party to a dispute. It does set conduct rules, may change the acceptable use policy at any time, interprets and enforces it at its sole discretion, may take corrective action or disable a transaction or a partner account, may require a merchant to drop a platform provider, and may update or modify the API. The Google entity that provides the consumer wallet in each country was not read.", "kind": "service_provider", "relations": [ { "type": "sourced_from", "to": "google-pay:src.google-pay-api-tos", "section": "sections 1 and 3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "google-pay:src.acceptable-use-policy", "section": "opening paragraphs", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Google Pay API Terms of Service sections 1 and 3; Google Pay and Wallet APIs Acceptable Use Policy; read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2021-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the effective date the terms state. Whether a later edition exists was not checked; the terms host disallows robots, so a person re-reads the page each quarter.", "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": "google-pay:src.google-pay-api-tos", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms Google shares payment credentials without being a party to the sale or to a dispute, and reserves rights to change the acceptable use policy, take corrective action and update the API." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "google-pay:exc.api-call-rejected", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:exc.api-call-rejected", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:exc.google-corrective-action", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:exc.google-corrective-action", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.api-status-codes", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.card-filtering-parameters", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.enablement-is-not-authorisation", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.google-is-not-a-party", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.google-may-take-corrective-action", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.is-ready-to-pay-use", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.merchant-resolves-disputes", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.payload-encrypted-to-the-merchant", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.personal-information-duties", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.who-the-agreement-binds-and-what-it-incorporates", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "google-pay:role.merchant", "id": "role.merchant", "rail": "google-pay", "class": "Role", "name": "Merchant (the seller)", "summary": "The party that sells the goods or services and accepts the credential Google shares. The terms call it You. It must hold its own card acquiring agreement, comply with that agreement and the applicable payment network rules, resolve its own disputes with End Users, follow the acceptable use policy and the brand guidelines, keep its own risk checks, and answer for taxes. It may use personal information from the API only for the current transaction and its post-transaction activities unless the End User consents to more.", "kind": "party", "relations": [ { "type": "sourced_from", "to": "google-pay:src.google-pay-api-tos", "section": "sections 1, 3, 5 and 7", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "google-pay:src.web-request-objects", "section": "CardParameters, allowedAuthMethods note", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Google Pay API Terms of Service sections 1, 3, 5 and 7; request objects reference; read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2021-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the effective date the terms state. Whether a later edition exists was not checked; the terms host disallows robots, so a person re-reads the page each quarter.", "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": "google-pay:src.google-pay-api-tos", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the merchant must hold its own acquiring agreement, resolve its own disputes, follow the acceptable use policy, and answer for taxes on payments made through the API." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "google-pay:exc.payload-rejected", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:exc.payload-rejected", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.assurance-details", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.bona-fide-sale-only", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.card-filtering-parameters", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.eci-indicator-unaltered", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.eea-strong-customer-authentication", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.enablement-is-not-authorisation", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.google-is-not-a-party", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.is-ready-to-pay-use", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.merchant-keeps-its-own-risk-checks", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.merchant-needs-its-own-acquiring-agreement", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.merchant-resolves-disputes", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.message-expiration", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.no-buyer-specific-minimum-maximum-or-surcharge", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.no-staged-wallet-behind-google-pay", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.no-wallet-refund-route", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.pan-only-is-not-a-token", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.payload-encrypted-to-the-merchant", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.payload-verification-steps", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.personal-information-duties", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.platform-provider-acts-for-the-merchant", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.restricted-products-and-services", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.two-authentication-methods", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.who-the-agreement-binds-and-what-it-incorporates", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "google-pay:role.platform-provider", "id": "role.platform-provider", "rail": "google-pay", "class": "Role", "name": "Platform provider", "summary": "A party a merchant arranges to help it integrate its payment interfaces with the Google Pay API. It must act exclusively on the merchant's behalf and under its own written agreement with Google, and Google may require the merchant to disengage from it where, in Google's discretion, it contributed to a breach of the terms or other harm to Google.", "kind": "service_provider", "relations": [ { "type": "sourced_from", "to": "google-pay:src.google-pay-api-tos", "section": "section 3, second paragraph", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Google Pay API Terms of Service section 3, read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2021-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the effective date the terms state. Whether a later edition exists was not checked; the terms host disallows robots, so a person re-reads the page each quarter.", "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": "google-pay:src.google-pay-api-tos", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms a platform provider must act exclusively on the merchant's behalf under its own written agreement with Google." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "google-pay:rule.platform-provider-acts-for-the-merchant", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "google-pay:rule.api-status-codes", "id": "rule.api-status-codes", "rail": "google-pay", "class": "Rule", "name": "The four status codes a rejected API call returns", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "google-pay:src.web-error-objects", "section": "PaymentsError; status codes", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "google-pay:role.google", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "google-pay:exc.api-call-rejected", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:messages", "note": "A decline of the payment itself carries a network code, not one of these.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:messages", "note": "A decline of the payment itself carries a network code, not one of these.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Error objects reference, read in full 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2025-02-10", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the last-updated date the page prints, which dates the page and not the values; they may be older [Unverified].", "source_edition": "Google Pay API for web, error objects reference, last updated 2025-02-10 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": "google-pay:src.web-error-objects", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the PaymentsError object's statusCode and statusMessage fields and the four status codes for a buyer account error, a developer error, a merchant account error and an internal error." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "google-pay:exc.api-call-rejected", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "google-pay:rule.assurance-details", "id": "rule.assurance-details", "rail": "google-pay", "class": "Rule", "name": "What assuranceDetails says about the credential", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "google-pay:src.web-response-objects", "section": "CardInfo, assuranceDetails; AssuranceDetailsSpecifications", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "google-pay:src.web-request-objects", "section": "CardParameters, assuranceDetailsRequired", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "google-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "google-pay:txn.device-token-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "google-pay:txn.card-on-file-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:liability", "note": "What authentication is worth in a dispute is the network's rule.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:liability", "note": "What authentication is worth in a dispute is the network's rule.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Response objects reference; request objects reference; read 2026-09-20. Who performed the identification and verification is not stated on the page; that it is the issuer is [Inference].", "confidence": "high" }, "currency": { "effective_since": "2026-08-24", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the last-updated date the page prints, which dates the page and not the rule; the field or behaviour may be older [Unverified].", "source_edition": "Google Pay API for web, response objects reference, last updated 2026-08-24 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": "google-pay:src.web-response-objects", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the assuranceDetails object's accountVerified and cardHolderAuthenticated fields and Google's guidance on when a step-up is and is not needed." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "google-pay:rule.bona-fide-sale-only", "id": "rule.bona-fide-sale-only", "rail": "google-pay", "class": "Rule", "name": "The API may be used only for a genuine sale by the merchant", "statement": "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.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "google-pay:src.google-pay-api-tos", "section": "section 2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "google-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Google Pay API Terms of Service section 2, read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2021-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the effective date the terms state. Whether a later edition exists was not checked; the terms host disallows robots, so a person re-reads the page each quarter.", "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": "google-pay:src.google-pay-api-tos", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the API may be used only for a bona fide sale a buyer starts, the non-profit donation exception, the web-only rule for digital goods, and the regulated financial services warranty." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "google-pay:rule.card-filtering-parameters", "id": "rule.card-filtering-parameters", "rail": "google-pay", "class": "Rule", "name": "What else the merchant's card parameters decide", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "google-pay:src.web-request-objects", "section": "CardParameters", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "google-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "google-pay:role.google", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Request objects reference, CardParameters, read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2026-09-17", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the last-updated date the page prints, which dates the page and not the rule; the field or behaviour may be older [Unverified].", "source_edition": "Google Pay API for web, request objects reference, last updated 2026-09-17 UTC as the page states, read 2026-09-20 from the copy saved that day", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "google-pay:src.web-request-objects", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the card networks Google names, the Brazilian combo card networks and country requirement, the prepaid and credit card toggles, the mutually exclusive issuer country lists, and the billing address friction note." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "google-pay:rule.eci-indicator-unaltered", "id": "rule.eci-indicator-unaltered", "rail": "google-pay", "class": "Rule", "name": "An ECI indicator must be passed on unaltered, and only device tokens carry one", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "google-pay:src.payment-data-cryptography", "section": "CRYPTOGRAM_3DS; eciIndicator", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "google-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "google-pay:txn.device-token-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:liability", "note": "What an ECI value means for liability is the network's rule.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:liability", "note": "What an ECI value means for liability is the network's rule.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Payment data cryptography, read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2026-02-20", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the last-updated date the page prints, which dates the page and not the rule; the field or behaviour may be older [Unverified].", "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": "google-pay:src.payment-data-cryptography", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms a merchant receiving an eciIndicator for an authenticated device-token transaction must pass it on unaltered or the transaction fails, and that the field returns only for CRYPTOGRAM_3DS." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "google-pay:rule.eea-strong-customer-authentication", "id": "rule.eea-strong-customer-authentication", "rail": "google-pay", "class": "Rule", "name": "Payments processed in the European Economic Area must meet strong customer authentication", "statement": "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.", "rests_on": "guidance", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "google-pay:src.sca-guide", "section": "whole page", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "google-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "google-pay:txn.card-on-file-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "google-pay:txn.device-token-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:consumer-law", "note": "The network's own consumer layer.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:consumer-law", "note": "The network's own consumer layer.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "SCA and Google Pay API, read in full 2026-09-20. The directive itself was not read; this records what Google tells merchants the requirement is and what Google returns, not what the law says.", "confidence": "medium" }, "currency": { "effective_since": "2025-03-11", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the last-updated date the page prints. The underlying requirement is PSD2, which was not read; the page is the source for what Google returns, not for the law.", "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": "google-pay:src.sca-guide", "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, the PaymentDataRequest fields a version 2 integration must send, and the two possible responses." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "google-pay:rule.enablement-is-not-authorisation", "id": "rule.enablement-is-not-authorisation", "rail": "google-pay", "class": "Rule", "name": "Enabling a payment promises neither authorisation nor freedom from chargeback", "statement": "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.", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "google-pay:src.google-pay-api-tos", "section": "section 1, fourth bullet", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "google-pay:role.google", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "google-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "google-pay:txn.device-token-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "google-pay:txn.card-on-file-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:finality", "note": "Where a payment becomes final is the network's rule.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:finality", "note": "Where a payment becomes final is the network's rule.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Google Pay API Terms of Service section 1, read 2026-09-20. The last sentence is Orca's reading of what the clause is for [Inference].", "confidence": "high" }, "currency": { "effective_since": "2021-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the effective date the terms state. Whether a later edition exists was not checked; the terms host disallows robots, so a person re-reads the page each quarter.", "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": "google-pay:src.google-pay-api-tos", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms Google's enablement of a transaction does not mean the instrument has sufficient funds or that the transaction will be authorised, processed or free of a later chargeback." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "google-pay:rule.google-eci-table-is-not-the-network-rule", "id": "rule.google-eci-table-is-not-the-network-rule", "rail": "google-pay", "class": "Rule", "name": "Google's liable-party table is Google describing network rules, not setting them", "statement": "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.", "rests_on": "guidance", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "google-pay:src.payment-data-cryptography", "section": "eciIndicator table", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "applies_to", "to": "google-pay:txn.device-token-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:liability", "note": "Visa's own rules, which govern.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:liability", "note": "Mastercard's own rules, which govern.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa-dispute:10.4", "note": "A card-absent fraud dispute condition, where an ECI value is one input among several.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Payment data cryptography, the eciIndicator table, read 2026-09-20. The values and pairings are recorded because they are what the page says; nothing here is asserted as a network rule, and no Visa or Mastercard document was read for this rail [Unverified against both networks].", "confidence": "medium" }, "currency": { "effective_since": "2026-02-20", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the last-updated date the page prints, which dates the page and not the rule; the field or behaviour may be older [Unverified].", "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": "google-pay:src.payment-data-cryptography", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the eciIndicator table pairing values with Visa and Mastercard and a liable party, limited to the CRYPTOGRAM_3DS authentication method, and that no other Visa or Mastercard value will be returned." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "google-pay:rule.google-is-not-a-party", "id": "rule.google-is-not-a-party", "rail": "google-pay", "class": "Rule", "name": "Google is not a party to the sale", "statement": "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.", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "google-pay:src.google-pay-api-tos", "section": "section 1, first three bullets", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "google-pay:role.google", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "google-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "google-pay:txn.device-token-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "google-pay:txn.card-on-file-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:finality", "note": "Whether the payment is final is the network's rule.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:finality", "note": "Whether the payment is final is the network's rule.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Google Pay API Terms of Service section 1, read 2026-09-20. The last sentence states the consequence of the clause [Inference]; the card networks' own definitions of a pass-through wallet were not read for this rail.", "confidence": "high" }, "currency": { "effective_since": "2021-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the effective date the terms state. Whether a later edition exists was not checked; the terms host disallows robots, so a person re-reads the page each quarter.", "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": "google-pay:src.google-pay-api-tos", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms Google only enables a transaction by sharing payment credentials, that the sale is solely between the merchant and the End User, and that Google is not responsible for the End User's acts." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "google-pay:rule.google-may-take-corrective-action", "id": "rule.google-may-take-corrective-action", "rail": "google-pay", "class": "Rule", "name": "Google may change the policy and act against a transaction or a partner", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "google-pay:src.acceptable-use-policy", "section": "opening paragraphs", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "google-pay:role.google", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "google-pay:exc.google-corrective-action", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Google Pay and Wallet APIs Acceptable Use Policy, read in full 2026-09-20. That there is no notice, procedure or review is an absence in the page, not a statement in it [Inference].", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the effective date the policy states is not a real calendar date", "effective_to": null, "effective_note": "Drafted 2026-09-20. The policy states it is effective on April 31, 2025, a date that does not exist, so no effective date can be recorded [Unverified]. The policy says Google may expand or edit it at any time.", "source_edition": "Google Pay and Wallet APIs Acceptable Use Policy, the page states it is effective on April 31, 2025, a date that does not exist; 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": "google-pay:src.acceptable-use-policy", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms Google's reserved right to expand or edit the policy at any time, to interpret and enforce it at its sole discretion, to take corrective action, to disable a transaction or partner account, and to report illegal activity, with no notice or review procedure stated." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "google-pay:exc.google-corrective-action", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "google-pay:rule.help-page-sends-the-user-to-the-bank", "id": "rule.help-page-sends-the-user-to-the-bank", "rail": "google-pay", "class": "Rule", "name": "Google's help page sends a disputing user to the store, then to the bank", "statement": "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.", "rests_on": "guidance", "facet": "return", "relations": [ { "type": "sourced_from", "to": "google-pay:src.help-dispute-7644016", "section": "steps 1, 3 and 4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "google-pay:role.cardholder", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:return", "note": "The dispute the bank then raises runs under the network's rules.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:return", "note": "The dispute the bank then raises runs under the network's rules.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Google Pay Help 7644016, read in full 2026-09-20. The page mixes Google's own sales, where Google is the seller, with payments to other merchants; only the lines about payments to other merchants are used here.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the help page carries no date", "effective_to": null, "effective_note": "Drafted 2026-09-20. The help page carries no date, so when this guidance took effect cannot be given [Unverified].", "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": "google-pay:src.help-dispute-7644016", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the help page tells a user to compare an unrecognised payment with the bank's own application rather than old statements, to take the problem up with the store, and to contact the bank or card provider immediately for a suspected scam, and that a payment cannot be disputed until it has finished." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "google-pay:rule.is-ready-to-pay-use", "id": "rule.is-ready-to-pay-use", "rail": "google-pay", "class": "Rule", "name": "What the isReadyToPay call may be used for", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "google-pay:src.google-pay-api-tos", "section": "section 3, first paragraph", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "google-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "google-pay:role.google", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Google Pay API Terms of Service section 3, read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "2021-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the effective date the terms state. Whether a later edition exists was not checked; the terms host disallows robots, so a person re-reads the page each quarter.", "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": "google-pay:src.google-pay-api-tos", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the merchant may use isReadyToPay only to decide whether to show or suppress Google Pay and must delete the data it receives immediately afterwards." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "google-pay:rule.merchant-keeps-its-own-risk-checks", "id": "rule.merchant-keeps-its-own-risk-checks", "rail": "google-pay", "class": "Rule", "name": "The merchant keeps its own risk checks", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "google-pay:src.web-request-objects", "section": "CardParameters, allowedAuthMethods, the important note", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "google-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "google-pay:txn.device-token-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "google-pay:txn.card-on-file-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Request objects reference, CardParameters, read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2026-09-17", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the last-updated date the page prints, which dates the page and not the rule; the field or behaviour may be older [Unverified].", "source_edition": "Google Pay API for web, request objects reference, last updated 2026-09-17 UTC as the page states, read 2026-09-20 from the copy saved that day", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "google-pay:src.web-request-objects", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms Google's note that a merchant's existing risk checks and controls must also apply to Google Pay transactions, because Google's own validation and fraud checks are not meant to replace them." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "google-pay:rule.merchant-needs-its-own-acquiring-agreement", "id": "rule.merchant-needs-its-own-acquiring-agreement", "rail": "google-pay", "class": "Rule", "name": "The merchant must hold its own card acquiring agreement", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "google-pay:src.google-pay-api-tos", "section": "section 1, fifth bullet", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "google-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "google-pay:role.card-acquiring-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:settlement", "note": "How the money settles is the network's rule.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:settlement", "note": "How the money settles is the network's rule.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "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. The date is the effective date the terms state. Whether a later edition exists was not checked; the terms host disallows robots, so a person re-reads the page each quarter.", "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": "google-pay:src.google-pay-api-tos", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the merchant alone is responsible for its card acquiring agreement, for its fees, and for complying with that agreement and applicable payment network rules." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "google-pay:rule.merchant-resolves-disputes", "id": "rule.merchant-resolves-disputes", "rail": "google-pay", "class": "Rule", "name": "The merchant alone resolves disputes with its buyers", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "google-pay:src.google-pay-api-tos", "section": "section 1, sixth bullet", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "google-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "google-pay:role.google", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:return", "note": "The dispute rules for the payment are Visa's.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:return", "note": "The dispute rules for the payment are Mastercard's.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa-dispute:10.4", "note": "A card-absent fraud dispute, the condition a web wallet payment falls under.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa-dispute:13.1", "note": "Merchandise or services not received, a dispute about the sale rather than the wallet.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Google Pay API Terms of Service section 1, 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": "high" }, "currency": { "effective_since": "2021-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the effective date the terms state. Whether a later edition exists was not checked; the terms host disallows robots, so a person re-reads the page each quarter.", "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": "google-pay:src.google-pay-api-tos", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the merchant is solely responsible for investigating and resolving disputes with End Users and that Google is not a party to a dispute." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "google-pay:rule.message-expiration", "id": "rule.message-expiration", "rail": "google-pay", "class": "Rule", "name": "The payload expires, and an expired one must be rejected", "statement": "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.", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "google-pay:src.payment-data-cryptography", "section": "steps for consuming the payload; encrypted message, messageExpiration", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "google-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "google-pay:txn.device-token-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "google-pay:txn.card-on-file-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "google-pay:exc.payload-rejected", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:hours", "note": "The hours that matter for the payment are the network's.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:hours", "note": "The hours that matter for the payment are the network's.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Payment data cryptography, read in full 2026-09-20. No duration is typed because the page gives none; the field carries an absolute time set per message.", "confidence": "high" }, "currency": { "effective_since": "2026-02-20", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the last-updated date the page prints, which dates the page and not the rule; the field or behaviour may be older [Unverified].", "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": "google-pay:src.payment-data-cryptography", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the decrypted payload's messageExpiration field, the duty to reject an expired message, and the duty to check the intermediate signing key's expiry." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "google-pay:exc.payload-rejected", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "google-pay:rule.no-buyer-specific-minimum-maximum-or-surcharge", "id": "rule.no-buyer-specific-minimum-maximum-or-surcharge", "rail": "google-pay", "class": "Rule", "name": "No buyer-specific minimum, maximum or surcharge, and no extra card numbers", "statement": "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.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "google-pay:src.google-pay-api-tos", "section": "section 4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "google-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "google-pay:txn.device-token-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "google-pay:txn.card-on-file-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:limits", "note": "Any limit on the payment itself is the network's and the card's.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:limits", "note": "Any limit on the payment itself is the network's and the card's.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Google Pay API Terms of Service section 4, read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2021-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the effective date the terms state. Whether a later edition exists was not checked; the terms host disallows robots, so a person re-reads the page each quarter.", "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": "google-pay:src.google-pay-api-tos", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the merchant may not set a buyer-specific minimum or maximum amount, may not require extra account numbers, and may not add a buyer-specific surcharge." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "google-pay:rule.no-staged-wallet-behind-google-pay", "id": "rule.no-staged-wallet-behind-google-pay", "rail": "google-pay", "class": "Rule", "name": "A staged wallet may not sit behind Google Pay", "statement": "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.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "google-pay:src.acceptable-use-policy", "section": "Restricted products and services, Financial Services", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "google-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "google-pay:exc.google-corrective-action", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "paypal:participants", "note": "A staged wallet is the other family; Orca holds PayPal as its own rail.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Google Pay and Wallet APIs Acceptable Use Policy, read in full 2026-09-20. The last sentence states what the rule is for, drawn from the two cases the policy names [Inference].", "confidence": "high" }, "currency": { "effective_since": "2026-09-20", "effective_to": null, "effective_note": "Drafted 2026-09-20. The policy states it is effective on April 31, 2025, a date that does not exist, so no effective date can be recorded [Unverified]. The policy says Google may expand or edit it at any time. The limits facet has to carry an ISO effective_since and the policy's stated effective date is not a real date, so the date is the day the page was read; it dates the reading, not the rule [Unverified].", "source_edition": "Google Pay and Wallet APIs Acceptable Use Policy, the page states it is effective on April 31, 2025, a date that does not exist; 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": "google-pay:src.acceptable-use-policy", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the prohibition on a transaction where a second payment completes the first or a substitute merchant of record stands in." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "google-pay:rule.no-wallet-recall", "id": "rule.no-wallet-recall", "rail": "google-pay", "class": "Rule", "name": "Google publishes no way to recall a completed payment to a merchant", "statement": "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.", "rests_on": "guidance", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "google-pay:src.help-dispute-7644016", "section": "steps 2, 3 and 4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "google-pay:src.google-pay-api-tos", "section": "section 1", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:recall", "note": "Where a card payment can be recalled, the rule is the network's.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:recall", "note": "Where a card payment can be recalled, the rule is the network's.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Google Pay Help 7644016; Google Pay API Terms of Service section 1; read 2026-09-20. This is a claim that nothing exists, drawn from reading the saved pages and finding no such route [Inference]; Google's wider help site was not read [Unverified].", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the help page carries no date", "effective_to": null, "effective_note": "Drafted 2026-09-20. The help page carries no date, so when this guidance took effect cannot be given [Unverified].", "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": "google-pay:src.help-dispute-7644016", "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, subscriptions and Play or YouTube purchases, and that a payment to another merchant is left to the store, the bank and the card provider." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "google-pay:rule.no-wallet-refund-route", "id": "rule.no-wallet-refund-route", "rail": "google-pay", "class": "Rule", "name": "Google publishes no refund route of its own for a merchant sale", "statement": "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.", "rests_on": "guidance", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "google-pay:src.google-pay-api-tos", "section": "sections 1 and 5(a)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "google-pay:src.help-dispute-7644016", "section": "whole page", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "google-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:refund", "note": "How a refund reaches the card is the network's rule.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:refund", "note": "How a refund reaches the card is the network's rule.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Google Pay API Terms of Service sections 1 and 5(a); Google Pay Help 7644016; read 2026-09-20. The help page's separate Return a purchase topic was not read [Unverified].", "confidence": "medium" }, "currency": { "effective_since": "2021-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the effective date the terms state. Whether a later edition exists was not checked; the terms host disallows robots, so a person re-reads the page each quarter.", "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": "google-pay:src.google-pay-api-tos", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the terms set no refund mechanism for a payment to a third-party merchant and that a merchant may keep using End User personal information for post-transaction activities such as a chargeback." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "google-pay:rule.pan-only-is-not-a-token", "id": "rule.pan-only-is-not-a-token", "rail": "google-pay", "class": "Rule", "name": "A card-on-file payment is not a tokenised payment, and the token rules do not reach it", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "google-pay:src.web-request-objects", "section": "CardParameters, allowedAuthMethods", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "google-pay:src.payment-data-cryptography", "section": "PAN_ONLY; CRYPTOGRAM_3DS; eciIndicator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "google-pay:src.sca-guide", "section": "Handle the response object", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "google-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "google-pay:txn.card-on-file-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:liability", "note": "A card-absent card payment's liability rules are the network's.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:liability", "note": "A card-absent card payment's liability rules are the network's.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Request objects reference; payment data cryptography; SCA and Google Pay API; read 2026-09-20. That a card-on-file payment is an ordinary card-absent payment to the network is what follows from the absence of a cryptogram and an ECI value [Inference]; no network document was read for this rail.", "confidence": "high" }, "currency": { "effective_since": "2026-09-17", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the last-updated date the page prints, which dates the page and not the rule; the field or behaviour may be older [Unverified].", "source_edition": "Google Pay API for web, request objects reference, last updated 2026-09-17 UTC as the page states, read 2026-09-20 from the copy saved that day", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "google-pay:rule.payload-encrypted-to-the-merchant", "id": "rule.payload-encrypted-to-the-merchant", "rail": "google-pay", "class": "Rule", "name": "Google hands over an encrypted, signed payload and nothing else", "statement": "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].", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "google-pay:src.payment-data-cryptography", "section": "steps for consuming the payload; encryption public key format", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "google-pay:src.google-pay-api-tos", "section": "section 1", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "google-pay:role.google", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "google-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:settlement", "note": "Clearing and settlement are the network's.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:settlement", "note": "Clearing and settlement are the network's.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Payment data cryptography; Google Pay API Terms of Service section 1; read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2026-02-20", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the last-updated date the page prints, which dates the page and not the rule; the field or behaviour may be older [Unverified].", "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": "google-pay:src.payment-data-cryptography", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms Google recommends its Tink library for consuming the payload and that merchants rotate their encryption key pairs annually." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "google-pay:rule.payload-structure-and-fields", "id": "rule.payload-structure-and-fields", "rail": "google-pay", "class": "Rule", "name": "What the encrypted payload carries", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "google-pay:src.payment-data-cryptography", "section": "encrypted message; Card; PAN_ONLY; CRYPTOGRAM_3DS", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "google-pay:src.web-request-objects", "section": "merchant-initiated transaction objects, tokenUpdateUrl", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "google-pay:txn.device-token-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "google-pay:txn.card-on-file-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Payment data cryptography; request objects reference; read 2026-09-20. How a Google merchant token is revoked or disputed was not read, so no Mandate is drafted.", "confidence": "high" }, "currency": { "effective_since": "2026-02-20", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the last-updated date the page prints, which dates the page and not the rule; the field or behaviour may be older [Unverified].", "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": "google-pay:src.payment-data-cryptography", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the decrypted payload's outer fields, the CARD payment method, and the card credential fields, including the conditions for a merchantTokenId to appear." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "google-pay:rule.payload-verification-steps", "id": "rule.payload-verification-steps", "rail": "google-pay", "class": "Rule", "name": "The steps a merchant runs before it charges the payment method", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "google-pay:src.payment-data-cryptography", "section": "steps for consuming the payload", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "google-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "google-pay:exc.payload-rejected", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Payment data cryptography, read in full 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "2026-02-20", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the last-updated date the page prints, which dates the page and not the rule; the field or behaviour may be older [Unverified].", "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": "google-pay:src.payment-data-cryptography", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the six steps for consuming a version 2 payment method token, from fetching Google's root signing keys to checking the message has not expired, and that the Tink library performs the first six." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "google-pay:exc.payload-rejected", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "google-pay:rule.personal-information-duties", "id": "rule.personal-information-duties", "rail": "google-pay", "class": "Rule", "name": "What a merchant may do with the buyer's personal information", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "google-pay:src.google-pay-api-tos", "section": "sections 5 and 6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "google-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "google-pay:role.google", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Google Pay API Terms of Service sections 5 and 6, read 2026-09-20. These are data duties rather than payment protections; no consumer payment law was read for this rail.", "confidence": "high" }, "currency": { "effective_since": "2021-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the effective date the terms state. Whether a later edition exists was not checked; the terms host disallows robots, so a person re-reads the page each quarter.", "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": "google-pay:src.google-pay-api-tos", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the merchant's sole responsibility for its use of End User personal information, the limits on using it beyond the current transaction and post-transaction activities, the independent controller status under European Union data protection law, and the required data security controls." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "google-pay:rule.platform-provider-acts-for-the-merchant", "id": "rule.platform-provider-acts-for-the-merchant", "rail": "google-pay", "class": "Rule", "name": "A platform provider acts only for the merchant", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "google-pay:src.google-pay-api-tos", "section": "section 3, second paragraph", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "google-pay:role.platform-provider", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "google-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Google Pay API Terms of Service section 3, read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2021-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the effective date the terms state. Whether a later edition exists was not checked; the terms host disallows robots, so a person re-reads the page each quarter.", "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": "google-pay:src.google-pay-api-tos", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms a platform provider must act exclusively on the merchant's behalf under its own written agreement with Google, and that Google may require the merchant to disengage from it." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "google-pay:rule.restricted-products-and-services", "id": "rule.restricted-products-and-services", "rail": "google-pay", "class": "Rule", "name": "The product and service classes that may not use the APIs", "statement": "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.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "google-pay:src.acceptable-use-policy", "section": "Restricted products and services", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "google-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "google-pay:exc.google-corrective-action", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Google Pay and Wallet APIs Acceptable Use Policy, read in full 2026-09-20. The classes are Google's; the grouping and order here are Orca's, and Google states its list is not exhaustive. The Google Wallet passes parts of the policy are outside this rail.", "confidence": "high" }, "currency": { "effective_since": "2026-09-20", "effective_to": null, "effective_note": "Drafted 2026-09-20. The policy states it is effective on April 31, 2025, a date that does not exist, so no effective date can be recorded [Unverified]. The policy says Google may expand or edit it at any time. The limits facet has to carry an ISO effective_since and the policy's stated effective date is not a real date, so the date is the day the page was read; it dates the reading, not the rule [Unverified].", "source_edition": "Google Pay and Wallet APIs Acceptable Use Policy, the page states it is effective on April 31, 2025, a date that does not exist; 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": "google-pay:src.acceptable-use-policy", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the licence-gated, barred and content-based restrictions the acceptable use policy lists for a biller or partner." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "google-pay:exc.google-corrective-action", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "google-pay:rule.two-authentication-methods", "id": "rule.two-authentication-methods", "rail": "google-pay", "class": "Rule", "name": "The two authentication methods a merchant may accept", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "google-pay:src.web-request-objects", "section": "CardParameters, allowedAuthMethods", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "google-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "google-pay:txn.device-token-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "google-pay:txn.card-on-file-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Request objects reference, CardParameters, read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2026-09-17", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the last-updated date the page prints, which dates the page and not the rule; the field or behaviour may be older [Unverified].", "source_edition": "Google Pay API for web, request objects reference, last updated 2026-09-17 UTC as the page states, read 2026-09-20 from the copy saved that day", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "google-pay:src.web-request-objects", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms the PAN_ONLY and CRYPTOGRAM_3DS authentication methods and their returned payment data, and that JCB and Discover do not support CRYPTOGRAM_3DS." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "google-pay:rule.who-the-agreement-binds-and-what-it-incorporates", "id": "rule.who-the-agreement-binds-and-what-it-incorporates", "rail": "google-pay", "class": "Rule", "name": "Who the agreement binds, and what else the merchant must follow", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "google-pay:src.google-pay-api-tos", "section": "opening paragraph; sections 3 and 7", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "google-pay:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "google-pay:role.google", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Google Pay API Terms of Service, opening paragraph and sections 3 and 7, read 2026-09-20. The Google APIs Terms of Service and the brand guidelines were not read, so what they require is unknown here.", "confidence": "high" }, "currency": { "effective_since": "2021-03-01", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the effective date the terms state. Whether a later edition exists was not checked; the terms host disallows robots, so a person re-reads the page each quarter.", "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": "google-pay:src.google-pay-api-tos", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms accessing or using the API binds the user to the Google Pay API Terms of Service and the incorporated Google APIs Terms of Service, and that the merchant must also comply with the acceptable use guidelines, the brand guidelines and its own tax duties." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "google-pay:src.acceptable-use-policy", "id": "src.acceptable-use-policy", "rail": "google-pay", "class": "RuleSource", "name": "Google Pay and Wallet APIs Acceptable Use Policy", "summary": "Google's conduct rules for developers using the Google Pay and Google Wallet APIs. It lists the product and service classes that may not be sold through the APIs, including the staged-wallet case where a second payment completes the first or a substitute merchant of record stands in, and it reserves to Google the right to change the policy at any time, to interpret and enforce it at its sole discretion, to take corrective action, to disable a transaction or a partner account for any reason it deems prudent, and to report illegal activity.", "publisher": "Google LLC", "url": "https://payments.developers.google.com/terms/aup", "source_class": "authoritative_primary", "kind": "web_page", "edition": "Google Pay and Wallet APIs Acceptable Use Policy, the page states it is effective on April 31, 2025, a date that does not exist; read in full 2026-09-20 from the copy saved that day", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, opened and read on 2026-09-20 from the copy saved that day in the wallet source folder; its public URL is recorded above.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the effective date the policy states is not a real calendar date", "effective_to": null, "effective_note": "Created 2026-09-20 for this rail. A RuleSource describes one edition of one document; its status stays draft and its consulted_on dates the reading.", "source_edition": "Google Pay and Wallet APIs Acceptable Use Policy, the page states it is effective on April 31, 2025, a date that does not exist; read in full 2026-09-20 from the copy saved that day", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "google-pay:rail.google-pay", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:exc.google-corrective-action", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "google-pay:role.google", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.google-may-take-corrective-action", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "google-pay:rule.no-staged-wallet-behind-google-pay", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "google-pay:rule.restricted-products-and-services", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "google-pay:src.google-pay-api-tos", "id": "src.google-pay-api-tos", "rail": "google-pay", "class": "RuleSource", "name": "Google Pay API Terms of Service (effective 2021-03-01)", "summary": "The agreement between Google LLC and a seller that uses the Google Pay API, incorporating the Google APIs Terms of Service. It states that Google only enables a transaction by sharing payment credentials and is not a party to the sale, that the seller alone must hold a card acquiring agreement and resolve its own disputes, what the API may and may not be used for, that a platform provider must act exclusively for the seller, the bars on a buyer-specific minimum, maximum or surcharge, and the data privacy, data security, tax, co-marketing and arbitration terms.", "publisher": "Google LLC", "url": "https://payments.developers.google.com/terms/sellertos", "source_class": "authoritative_primary", "kind": "web_page", "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", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, opened and read on 2026-09-20 from the copy saved that day in the wallet source folder; its public URL is recorded above.", "confidence": "medium" }, "currency": { "effective_since": "2021-03-01", "effective_to": null, "effective_note": "Created 2026-09-20 for this rail. A RuleSource describes one edition of one document; its status stays draft and its consulted_on dates the reading.", "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": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "google-pay:rail.google-pay", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:exc.google-corrective-action", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:role.card-acquiring-bank", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "google-pay:role.cardholder", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "google-pay:role.google", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "google-pay:role.merchant", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "google-pay:role.platform-provider", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "google-pay:rule.bona-fide-sale-only", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "google-pay:rule.enablement-is-not-authorisation", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "google-pay:rule.google-is-not-a-party", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "google-pay:rule.is-ready-to-pay-use", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "google-pay:rule.merchant-needs-its-own-acquiring-agreement", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "google-pay:rule.merchant-resolves-disputes", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "google-pay:rule.no-buyer-specific-minimum-maximum-or-surcharge", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "google-pay:rule.no-wallet-recall", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.no-wallet-refund-route", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "google-pay:rule.payload-encrypted-to-the-merchant", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.personal-information-duties", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "google-pay:rule.platform-provider-acts-for-the-merchant", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "google-pay:rule.who-the-agreement-binds-and-what-it-incorporates", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "google-pay:src.help-dispute-7644016", "id": "src.help-dispute-7644016", "rail": "google-pay", "class": "RuleSource", "name": "Google Pay Help article 7644016, Dispute, report, or cancel a payment", "summary": "Google's consumer help page on disputing, reporting or cancelling a payment. It covers cancelling Google's own charges, where Google is the seller, and separately tells a user who does not recognise a payment to compare it with the bank's record and take it up with the store, and tells a user who suspects a scam or fraudulent charge they made to contact their bank or card provider immediately.", "publisher": "Google", "url": "https://support.google.com/googlepay/answer/7644016?hl=en", "source_class": "public_primary", "kind": "web_page", "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", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, opened and read on 2026-09-20 from the copy saved that day in the wallet source folder; its public URL is recorded above.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the help page carries no date", "effective_to": null, "effective_note": "Created 2026-09-20 for this rail. A RuleSource describes one edition of one document; its status stays draft and its consulted_on dates the reading.", "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": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "google-pay:role.card-issuer", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:role.cardholder", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.help-page-sends-the-user-to-the-bank", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "google-pay:rule.no-wallet-recall", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "google-pay:rule.no-wallet-refund-route", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "google-pay:src.payment-data-cryptography", "id": "src.payment-data-cryptography", "rail": "google-pay", "class": "RuleSource", "name": "Payment data cryptography for merchants", "summary": "Google's definition of the encrypted payment payload and the steps for consuming it: fetching the root signing keys, checking the intermediate key and the payload signature, decrypting, and rejecting an expired message. It tables the encrypted message fields, the card credential fields for PAN_ONLY and for CRYPTOGRAM_3DS, and the eciIndicator, and it prints a table pairing eciIndicator values with a liable party for Visa and Mastercard, which is Google restating network rules rather than setting them.", "publisher": "Google", "url": "https://developers.google.com/pay/api/web/guides/resources/payment-data-cryptography", "source_class": "authoritative_primary", "kind": "web_page", "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", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, opened and read on 2026-09-20 from the copy saved that day in the wallet source folder; its public URL is recorded above.", "confidence": "medium" }, "currency": { "effective_since": "2026-02-20", "effective_to": null, "effective_note": "Created 2026-09-20 for this rail. A RuleSource describes one edition of one document; its status stays draft and its consulted_on dates the reading.", "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": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "google-pay:rail.google-pay", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:exc.payload-rejected", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "google-pay:role.card-issuer", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:role.card-network", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.eci-indicator-unaltered", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "google-pay:rule.google-eci-table-is-not-the-network-rule", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "google-pay:rule.message-expiration", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "google-pay:rule.pan-only-is-not-a-token", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.payload-encrypted-to-the-merchant", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "google-pay:rule.payload-structure-and-fields", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "google-pay:rule.payload-verification-steps", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "google-pay:txn.card-on-file-payment", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:txn.device-token-payment", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "google-pay:src.sca-guide", "id": "src.sca-guide", "rail": "google-pay", "class": "RuleSource", "name": "SCA and Google Pay API", "summary": "Google's guidance on strong customer authentication. It states that online payments processed in European Economic Area countries must meet strong customer authentication under the second Payment Services Directive, lists the request fields a version 2 integration must send, and says a merchant receives either an authenticated payload it can process without a further challenge or a card number it must put through 3-D Secure 2.0 itself or through its payment service provider.", "publisher": "Google", "url": "https://developers.google.com/pay/api/web/guides/resources/sca", "source_class": "public_primary", "kind": "web_page", "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", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, opened and read on 2026-09-20 from the copy saved that day in the wallet source folder; its public URL is recorded above.", "confidence": "medium" }, "currency": { "effective_since": "2025-03-11", "effective_to": null, "effective_note": "Created 2026-09-20 for this rail. A RuleSource describes one edition of one document; its status stays draft and its consulted_on dates the reading.", "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": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "google-pay:role.card-acquiring-bank", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.eea-strong-customer-authentication", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "google-pay:rule.pan-only-is-not-a-token", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:txn.card-on-file-payment", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "google-pay:src.web-error-objects", "id": "src.web-error-objects", "rail": "google-pay", "class": "RuleSource", "name": "Google Pay API for web, error objects reference", "summary": "Google's definition of the PaymentsError object a rejected Google Pay API call returns, carrying a statusCode and a developer-facing statusMessage, and the four status codes: BUYER_ACCOUNT_ERROR, DEVELOPER_ERROR, MERCHANT_ACCOUNT_ERROR and INTERNAL_ERROR. They report integration, permission and account problems with the API call, not the outcome of a payment.", "publisher": "Google", "url": "https://developers.google.com/pay/api/web/reference/error-objects", "source_class": "authoritative_primary", "kind": "web_page", "edition": "Google Pay API for web, error objects reference, last updated 2025-02-10 UTC as the page states, read in full 2026-09-20 from the copy saved that day", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, opened and read on 2026-09-20 from the copy saved that day in the wallet source folder; its public URL is recorded above.", "confidence": "medium" }, "currency": { "effective_since": "2025-02-10", "effective_to": null, "effective_note": "Created 2026-09-20 for this rail. A RuleSource describes one edition of one document; its status stays draft and its consulted_on dates the reading.", "source_edition": "Google Pay API for web, error objects reference, last updated 2025-02-10 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": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "google-pay:exc.api-call-rejected", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "google-pay:rule.api-status-codes", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "google-pay:src.web-request-objects", "id": "src.web-request-objects", "rail": "google-pay", "class": "RuleSource", "name": "Google Pay API for web, request objects reference", "summary": "Google's interface definition for what a merchant sends. It defines CardParameters, where allowedAuthMethods declares whether the merchant accepts PAN_ONLY, a card stored on file with the user's Google Account, or CRYPTOGRAM_3DS, a card stored as an Android device token, along with the accepted card networks, whether prepaid and credit cards are allowed, mutually exclusive issuer country allow and block lists, and assuranceDetailsRequired. It also defines the merchant-initiated transaction objects that carry tokenUpdateUrl and managementUrl.", "publisher": "Google", "url": "https://developers.google.com/pay/api/web/reference/request-objects", "source_class": "authoritative_primary", "kind": "web_page", "edition": "Google Pay API for web, request objects reference, last updated 2026-09-17 UTC as the page states, read 2026-09-20 from the copy saved that day", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, opened and read on 2026-09-20 from the copy saved that day in the wallet source folder; its public URL is recorded above.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-17", "effective_to": null, "effective_note": "Created 2026-09-20 for this rail. A RuleSource describes one edition of one document; its status stays draft and its consulted_on dates the reading.", "source_edition": "Google Pay API for web, request objects reference, last updated 2026-09-17 UTC as the page states, read 2026-09-20 from the copy saved that day", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "google-pay:role.card-network", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "google-pay:role.merchant", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.assurance-details", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.card-filtering-parameters", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "google-pay:rule.merchant-keeps-its-own-risk-checks", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "google-pay:rule.pan-only-is-not-a-token", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.payload-structure-and-fields", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.two-authentication-methods", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "google-pay:txn.card-on-file-payment", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:txn.device-token-payment", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "google-pay:src.web-response-objects", "id": "src.web-response-objects", "rail": "google-pay", "class": "RuleSource", "name": "Google Pay API for web, response objects reference", "summary": "Google's interface definition for what a merchant receives: the payment data, the card information including the card network and funding source, and AssuranceDetailsSpecifications, whose accountVerified says cardholder possession validation was performed on the returned credential and whose cardHolderAuthenticated says identification and verification was performed, with Google's guidance on when a step-up is and is not needed.", "publisher": "Google", "url": "https://developers.google.com/pay/api/web/reference/response-objects", "source_class": "authoritative_primary", "kind": "web_page", "edition": "Google Pay API for web, response objects reference, last updated 2026-08-24 UTC as the page states, read in full 2026-09-20 from the copy saved that day", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, opened and read on 2026-09-20 from the copy saved that day in the wallet source folder; its public URL is recorded above.", "confidence": "medium" }, "currency": { "effective_since": "2026-08-24", "effective_to": null, "effective_note": "Created 2026-09-20 for this rail. A RuleSource describes one edition of one document; its status stays draft and its consulted_on dates the reading.", "source_edition": "Google Pay API for web, response objects reference, last updated 2026-08-24 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": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "google-pay:role.card-issuer", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.assurance-details", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "google-pay:txn.card-on-file-payment", "id": "txn.card-on-file-payment", "rail": "google-pay", "class": "TransactionType", "name": "Google Pay payment with a card on file (PAN_ONLY)", "summary": "A payment where the credential Google returns is the card number the user saved to their Google Account, with its expiry month and year and no cryptogram. It is an ordinary card-absent card payment that happens to have been filled in from the Google Account, so none of the device-token rules reaches it: there is no cryptogram, no eciIndicator and no entry in Google's liable-party table. Where the transaction needs strong customer authentication, or where assuranceDetails reports that the cardholder was not authenticated, the merchant must run 3-D Secure itself or through its payment service provider.", "sec_code": null, "directions": [ "debit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "google-pay:src.web-request-objects", "section": "CardParameters, allowedAuthMethods", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "google-pay:src.payment-data-cryptography", "section": "PAN_ONLY", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "google-pay:src.sca-guide", "section": "Handle the response object", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa:messages", "note": "A card-absent card payment on the network.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:messages", "note": "A card-absent card payment on the network.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Request objects reference, CardParameters; payment data cryptography, PAN_ONLY; SCA and Google Pay API; read 2026-09-20. sec_code is null.", "confidence": "high" }, "currency": { "effective_since": "2026-09-17", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the last-updated date the page prints, which dates the page and not the rule; the field or behaviour may be older [Unverified].", "source_edition": "Google Pay API for web, request objects reference, last updated 2026-09-17 UTC as the page states, read 2026-09-20 from the copy saved that day", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "google-pay:rule.assurance-details", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.eea-strong-customer-authentication", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.enablement-is-not-authorisation", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.google-is-not-a-party", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.merchant-keeps-its-own-risk-checks", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.message-expiration", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.no-buyer-specific-minimum-maximum-or-surcharge", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.pan-only-is-not-a-token", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.payload-structure-and-fields", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.two-authentication-methods", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "google-pay:txn.device-token-payment", "id": "txn.device-token-payment", "rail": "google-pay", "class": "TransactionType", "name": "Google Pay payment with an Android device token (CRYPTOGRAM_3DS)", "summary": "A payment where the credential Google returns is a card stored as an Android device token. The payment data carries a device account number, its expiry, an authentication method of CRYPTOGRAM_3DS, a 3-D Secure cryptogram generated on the device and, where the card network supplies one, an eciIndicator the merchant must pass on unaltered. This is the tokenised form: the eciIndicator, the cryptogram and Google's liable-party table belong to it and to nothing else. JCB and Discover do not support it.", "sec_code": null, "directions": [ "debit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "google-pay:src.web-request-objects", "section": "CardParameters, allowedAuthMethods", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "google-pay:src.payment-data-cryptography", "section": "CRYPTOGRAM_3DS; eciIndicator", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "visa:messages", "note": "The authorisation message is the network's.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:messages", "note": "The authorisation message is the network's.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Request objects reference, CardParameters; payment data cryptography; read 2026-09-20. sec_code is null: this is not an ACH rail and no scheme code names the type.", "confidence": "high" }, "currency": { "effective_since": "2026-09-17", "effective_to": null, "effective_note": "Drafted 2026-09-20. The date is the last-updated date the page prints, which dates the page and not the rule; the field or behaviour may be older [Unverified].", "source_edition": "Google Pay API for web, request objects reference, last updated 2026-09-17 UTC as the page states, read 2026-09-20 from the copy saved that day", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "google-pay:src.payment-data-cryptography", "checked_on": "2026-09-20", "checked_by": "validator-pass-through-wallets-2026-09-20", "notes": "Confirms a device-token payment carries a device account number, its expiry, the CRYPTOGRAM_3DS authentication method, a 3-D Secure cryptogram, and an eciIndicator where the card network supplies one." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "google-pay:rule.assurance-details", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.eci-indicator-unaltered", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.eea-strong-customer-authentication", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.enablement-is-not-authorisation", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.google-eci-table-is-not-the-network-rule", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.google-is-not-a-party", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.merchant-keeps-its-own-risk-checks", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.message-expiration", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.no-buyer-specific-minimum-maximum-or-surcharge", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.payload-structure-and-fields", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "google-pay:rule.two-authentication-methods", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "google-pay:rule.eea-strong-customer-authentication", "google-pay:rule.personal-information-duties", "google-pay:rule.google-is-not-a-party", "google-pay:rule.merchant-resolves-disputes" ], "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.", "relations": [ { "type": "see_also", "to": "visa:consumer-law", "note": "The Visa rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:consumer-law", "note": "The Mastercard rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "apple-pay:consumer-law", "note": "The same facet for the other pass-through wallet.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "google-pay:src.sca-guide", "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." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:consumer-law", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "google-pay:rule.card-filtering-parameters", "google-pay:rule.is-ready-to-pay-use", "google-pay:rule.payload-verification-steps", "google-pay:rule.assurance-details", "google-pay:rule.google-may-take-corrective-action", "google-pay:rule.platform-provider-acts-for-the-merchant" ], "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.", "relations": [ { "type": "see_also", "to": "visa:decision-points", "note": "The Visa rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:decision-points", "note": "The Mastercard rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "apple-pay:decision-points", "note": "The same facet for the other pass-through wallet.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "google-pay:src.web-request-objects", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:decision-points", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "google-pay:rule.google-is-not-a-party", "google-pay:rule.enablement-is-not-authorisation", "google-pay:rule.merchant-needs-its-own-acquiring-agreement", "google-pay:rule.payload-verification-steps", "google-pay:rule.message-expiration" ], "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.", "relations": [ { "type": "see_also", "to": "visa:finality", "note": "The Visa rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:finality", "note": "The Mastercard rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "apple-pay:finality", "note": "The same facet for the other pass-through wallet.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "google-pay:src.google-pay-api-tos", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:finality", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "google-pay:rule.message-expiration", "google-pay:rule.payload-verification-steps" ], "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.", "relations": [ { "type": "see_also", "to": "visa:hours", "note": "The Visa rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:hours", "note": "The Mastercard rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "apple-pay:hours", "note": "The same facet for the other pass-through wallet.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "google-pay:src.payment-data-cryptography", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:hours", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "google-pay:rule.google-is-not-a-party", "google-pay:rule.pan-only-is-not-a-token", "google-pay:rule.merchant-keeps-its-own-risk-checks", "google-pay:rule.assurance-details", "google-pay:rule.eci-indicator-unaltered", "google-pay:rule.google-eci-table-is-not-the-network-rule", "google-pay:rule.eea-strong-customer-authentication" ], "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.", "relations": [ { "type": "see_also", "to": "visa:liability", "note": "The Visa rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:liability", "note": "The Mastercard rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa-dispute:10.4", "note": "Visa other fraud, card-absent environment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa-dispute:10.1", "note": "Visa counterfeit fraud, a condition where a token matters.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "apple-pay:liability", "note": "The same facet for the other pass-through wallet.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:liability", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "google-pay:rule.no-buyer-specific-minimum-maximum-or-surcharge", "google-pay:rule.bona-fide-sale-only", "google-pay:rule.restricted-products-and-services", "google-pay:rule.no-staged-wallet-behind-google-pay", "google-pay:rule.google-may-take-corrective-action", "google-pay:rule.card-filtering-parameters" ], "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.", "relations": [ { "type": "see_also", "to": "visa:limits", "note": "The Visa rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:limits", "note": "The Mastercard rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "apple-pay:limits", "note": "The same facet for the other pass-through wallet.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "google-pay:src.google-pay-api-tos", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:limits", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "google-pay:rule.two-authentication-methods", "google-pay:rule.payload-structure-and-fields", "google-pay:rule.eci-indicator-unaltered", "google-pay:rule.card-filtering-parameters", "google-pay:rule.api-status-codes", "google-pay:rule.payload-verification-steps" ], "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.", "relations": [ { "type": "see_also", "to": "visa:messages", "note": "The Visa rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:messages", "note": "The Mastercard rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "apple-pay:messages", "note": "The same facet for the other pass-through wallet.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "google-pay:src.payment-data-cryptography", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:messages", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "google-pay:rule.google-is-not-a-party", "google-pay:rule.who-the-agreement-binds-and-what-it-incorporates", "google-pay:rule.platform-provider-acts-for-the-merchant", "google-pay:rule.merchant-needs-its-own-acquiring-agreement", "google-pay:rule.assurance-details", "google-pay:rule.merchant-keeps-its-own-risk-checks" ], "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.", "relations": [ { "type": "see_also", "to": "visa:participants", "note": "The Visa rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:participants", "note": "The Mastercard rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "apple-pay:participants", "note": "The same facet for the other pass-through wallet.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:participants", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "google-pay:rule.no-wallet-recall", "google-pay:rule.google-is-not-a-party", "google-pay:rule.payload-verification-steps", "google-pay:rule.message-expiration" ], "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].", "relations": [ { "type": "see_also", "to": "visa:recall", "note": "The Visa rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:recall", "note": "The Mastercard rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "apple-pay:recall", "note": "The same facet for the other pass-through wallet.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "google-pay:src.help-dispute-7644016", "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." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:recall", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "google-pay:rule.no-wallet-refund-route", "google-pay:rule.google-is-not-a-party", "google-pay:rule.pan-only-is-not-a-token", "google-pay:rule.personal-information-duties" ], "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].", "relations": [ { "type": "see_also", "to": "visa:refund", "note": "The Visa rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:refund", "note": "The Mastercard rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "apple-pay:refund", "note": "The same facet for the other pass-through wallet.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "google-pay:src.google-pay-api-tos", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:refund", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "google-pay:rule.merchant-resolves-disputes", "google-pay:rule.help-page-sends-the-user-to-the-bank", "google-pay:rule.google-is-not-a-party", "google-pay:rule.enablement-is-not-authorisation", "google-pay:rule.personal-information-duties" ], "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].", "relations": [ { "type": "see_also", "to": "visa:return", "note": "The Visa rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:return", "note": "The Mastercard rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa-dispute:10.4", "note": "Visa other fraud, card-absent environment, the condition a web wallet payment falls under.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "visa-dispute:13.1", "note": "Merchandise or services not received, a dispute about the sale rather than the wallet.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "apple-pay:return", "note": "The same facet for the other pass-through wallet.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "google-pay:src.google-pay-api-tos", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:return", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "google-pay:rule.payload-encrypted-to-the-merchant", "google-pay:rule.merchant-needs-its-own-acquiring-agreement", "google-pay:rule.google-is-not-a-party", "google-pay:rule.payload-verification-steps" ], "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.", "relations": [ { "type": "see_also", "to": "visa:settlement", "note": "The Visa rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mastercard:settlement", "note": "The Mastercard rules for this facet of the payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "apple-pay:settlement", "note": "The same facet for the other pass-through wallet.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "google-pay:src.payment-data-cryptography", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "apple-pay:settlement", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rail.in-upi", "id": "rail.in-upi", "class": "Rail", "rail": "in-upi", "name": "UPI (Unified Payments Interface)", "governing_authority": "Reserve Bank of India", "country": "IN", "currency": "INR", "operators": [ "National Payments Corporation of India (NPCI)" ], "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" ], "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-certificates-of-authorisation-2026-09-08", "section": "Retail Payments Organisation, entry 1, Unified Payments Interface, 24.08.2016", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-payment-systems-overview", "section": "legal frame, the systems NPCI operates, and the Payments Regulatory Board", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-tat-circular-2019", "section": "Annex, rows 4(a) and 4(b)", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "source_class": null, "effective_status_reason": null, "used_by": [] }, { "uid": "in-upi:exc.auto-reversal", "id": "exc.auto-reversal", "rail": "in-upi", "class": "Exception", "name": "Automatic reversal of a failed UPI payment", "summary": "The Reserve Bank's remedy for a UPI payment that did not complete for a reason the customer is not responsible for. The money goes back automatically, inside a deadline set by the kind of payment, and if it is late the customer is paid 100 rupees for every day of delay. Nobody has to ask for either. It is not a scheme return of a payment that worked and it is not the interbank dispute path, which is NPCI's and is not held.", "money_moves": true, "outcome": "The debited amount returns to the payer's account, at the latest on the day after the transaction for a transfer of funds and within five days for a payment to a merchant, and the payer's bank credits it the same day the funds come back. Delay beyond the deadline adds 100 rupees a day, credited without a complaint.", "relations": [ { "type": "initiated_by", "to": "in-upi:role.beneficiary-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "in-upi:role.beneficiary-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.auto-reversal-funds-transfer-next-day", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.auto-reversal-merchant-payment-five-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.compensation-hundred-rupees-a-day", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.compensation-without-a-complaint", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.what-counts-as-a-failed-transaction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.transaction-day-and-reversal-day", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.deadline-is-an-outer-limit", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-tat-circular-2019", "section": "Annex, rows 4(a) and 4(b) with general instructions 1 to 7", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "RBI/2019-20/67 and its Annex, read 2026-09-20. decided_by names the payee's bank because that is the party the funds transfer row binds; the merchant row names nobody, which is an [Inference] recorded on the rule rather than here.", "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 nothing here rests on UPI's own scheme rules.", "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": "in-upi:src.rbi-tat-circular-2019", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the automatic reversal and compensation mechanics for both UPI failure cases, credited without a complaint." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:rule.auto-reversal-funds-transfer-next-day", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.auto-reversal-merchant-payment-five-days", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.compensation-hundred-rupees-a-day", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.compensation-without-a-complaint", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.transaction-day-and-reversal-day", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.what-counts-as-a-failed-transaction", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:exc.odr-grievance", "id": "exc.odr-grievance", "rail": "in-upi", "class": "Exception", "name": "Grievance through the online dispute resolution system", "summary": "The path a UPI customer takes when a payment failed and the money did not come back as it should have. The operator runs a dispute resolution system for failed transactions, its participating members have access to it, and the customer can reach it through the operator, through their own bank, or, on UPI, through the app they paid in. It is meant to be rule driven with as little human judgement as possible.", "money_moves": true, "outcome": "The dispute is decided inside the operator's system, and the turn around time framework's deadlines and compensation apply while it is decided, so a successful grievance ends in the money and any accrued compensation reaching the customer. The customer gets a reference number and can follow the progress.", "relations": [ { "type": "initiated_by", "to": "in-upi:role.customer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "in-upi:role.npci", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "in-upi:role.payment-system-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.operator-must-run-dispute-resolution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.dispute-resolution-minimises-human-judgement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.dispute-resolution-scope-and-compensation", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.dispute-lodging-channels-and-tracking", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.tpap-in-app-dispute-lodging", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-odr-circular-2020", "section": "paragraph 3 and Annex 1 to 5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "RBI/2020-21/21 and its Annex, read 2026-09-20. How the operator's system actually reaches an answer is NPCI's to define and is not held.", "confidence": "high" }, "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 nothing here rests on UPI's own scheme rules.", "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": "in-upi:src.rbi-odr-circular-2020", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the operator-run dispute resolution system, its scope over the TAT circular's failed transactions, and the reference number for tracking." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.ombudsman-complaint", "type": "follows", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.dispute-lodging-channels-and-tracking", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.dispute-resolution-minimises-human-judgement", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.dispute-resolution-scope-and-compensation", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.operator-must-run-dispute-resolution", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.tpap-in-app-dispute-lodging", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:exc.ombudsman-complaint", "id": "exc.ombudsman-complaint", "rail": "in-upi", "class": "Exception", "name": "Complaint to an RBI Ombudsman", "summary": "Where a UPI customer goes when the institution and the operator have not put things right. It is free, it is outside the courts, and it is reached after the institution has had its chance. The turn around time and dispute resolution circulars both point customers here; both still name the 2021 scheme, which the Reserve Bank replaced with the 2026 scheme on 1 July 2026.", "money_moves": true, "outcome": "The complaint ends in a settlement the parties reach with the ombudsman's help, in an award directing the institution to act or to pay where deficiency in service is found, or in a rejection with reasons. An award may carry up to 30 lakh rupees for consequential loss and up to a further 3 lakh rupees for the complainant's time, expenses and distress.", "relations": [ { "type": "initiated_by", "to": "in-upi:role.customer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "in-upi:role.rbi-ombudsman", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "follows", "to": "in-upi:exc.odr-grievance", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.escalation-after-one-month", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.ombudsman-scheme-2021-covers-system-participants", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.ombudsman-scheme-2026-replaced-2021", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.ombudsman-when-a-complaint-may-be-filed", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.ombudsman-costs-nothing-and-what-it-can-award", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.ombudsman-how-a-complaint-ends", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-integrated-ombudsman-notification-2021", "section": "the notification", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-integrated-ombudsman-faq-2026", "section": "questions 1, 16, 17 and 21 to 26", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "The RBI Integrated Ombudsman notification of 12 November 2021 and the Reserve Bank's 2026 questions and answers updated 1 July 2026, read 2026-09-20. Neither scheme text was read: both are PDFs on a Reserve Bank host that returned nothing.", "confidence": "medium" }, "currency": { "effective_since": "2021-11-12", "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 nothing here rests on UPI's own scheme rules.", "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": "in-upi:src.rbi-integrated-ombudsman-notification-2021", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the 2021 scheme's commencement and coverage." }, { "source": "in-upi:src.rbi-integrated-ombudsman-faq-2026", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the free complaint process, the 1 July 2026 replacement of the 2021 scheme, and the settlement, award or rejection outcomes with the 30 lakh and 3 lakh rupee compensation ceilings." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:rule.escalation-after-one-month", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.ombudsman-costs-nothing-and-what-it-can-award", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.ombudsman-how-a-complaint-ends", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.ombudsman-scheme-2021-covers-system-participants", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.ombudsman-scheme-2026-replaced-2021", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.ombudsman-when-a-complaint-may-be-filed", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:exc.unauthorised-transaction-claim", "id": "exc.unauthorised-transaction-claim", "rail": "in-upi", "class": "Exception", "name": "Claim that the customer did not authorise the payment", "summary": "The path for a payment the customer says they never made. It is not the failed transaction path: the payment worked, and the question is who bears the loss. The customer reports it, the bank puts the money back first and settles liability afterwards, and the bank has to prove the customer owes anything at all. The Reserve Bank's circular covers remote payment transactions as a category and does not name UPI.", "money_moves": true, "outcome": "The bank credits the disputed amount within ten working days of the report, value dated to the day of the transaction. It then settles liability within its own policy's time and in no case beyond ninety days of the complaint, or pays regardless. The customer owes nothing where the bank was at fault, or where the fault was elsewhere and the report came within three working days; a capped amount where the report came within four to seven working days; and whatever the bank's published policy says beyond that. An issuer that authenticated against the rules pays the whole loss.", "relations": [ { "type": "initiated_by", "to": "in-upi:role.customer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "in-upi:role.remitter-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.zero-liability-for-the-customer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.limited-liability-for-the-customer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.money-back-within-ten-working-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.claim-settled-within-ninety-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.bank-must-prove-the-customer-is-liable", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.alerts-and-channels-for-reporting", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.issuer-pays-in-full-for-bad-authentication", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.e-mandate-disputes-and-liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-customer-liability-circular-2017", "section": "paragraphs 5 to 12", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-authentication-directions-2025", "section": "paragraph 9", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "RBI/2017-18/15 paragraphs 5 to 12 and RBI/2025-26/79 paragraph 9, read 2026-09-20. That the framework reaches a UPI payment is an [Inference] from the circular's 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 nothing here rests on UPI's own scheme rules.", "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": "in-upi:src.rbi-customer-liability-circular-2017", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the shadow reversal, the 90 day settlement deadline, the burden of proof, and the liability bands by fault and reporting speed." }, { "source": "in-upi:src.rbi-authentication-directions-2025", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that an issuer whose authentication did not comply with the directions bears the whole loss." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:mandate.upi-recurring", "type": "disputed_via", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.alerts-and-channels-for-reporting", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.bank-must-prove-the-customer-is-liable", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.claim-settled-within-ninety-days", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.e-mandate-disputes-and-liability", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.issuer-pays-in-full-for-bad-authentication", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.limited-liability-for-the-customer", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.money-back-within-ten-working-days", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.zero-liability-for-the-customer", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:mandate.upi-recurring", "id": "mandate.upi-recurring", "rail": "in-upi", "class": "Mandate", "name": "UPI recurring payment mandate", "summary": "A standing authorisation a customer gives so that money can be taken from their account again and again, which the Reserve Bank's recurring payment framework says covers UPI as well as cards and prepaid instruments. It is registered once behind an additional factor of authentication, carries a validity period the customer can change, and can be withdrawn at any time behind the same authentication. It may be for a fixed amount or for a varying one within a cap the customer sets. The customer is told at least a day before each charge, can opt out of that charge or of the mandate, and is told again after it. Nothing may be charged for having one.", "form": "electronic, registered once with the issuer behind an additional factor of authentication", "scope": [ "recurring", "fixed amount", "variable amount within a customer set maximum" ], "relations": [ { "type": "given_by", "to": "in-upi:role.customer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "given_to", "to": "in-upi:role.merchant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "authorises", "to": "in-upi:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.e-mandate-framework-covers-upi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.e-mandate-first-charge", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.e-mandate-notice-before-each-charge", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.e-mandate-notice-after-each-charge", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.e-mandate-authentication-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.e-mandate-higher-threshold-for-three-categories", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.e-mandate-costs-the-customer-nothing", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "evidenced_by", "to": "in-upi:rule.e-mandate-registration-and-withdrawal", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "revoked_via", "to": "in-upi:rule.e-mandate-registration-and-withdrawal", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "revoked_via", "to": "in-upi:rule.upi-autopay-revocation", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "disputed_via", "to": "in-upi:exc.unauthorised-transaction-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RBI/DPSS/2026-27/396, read 2026-09-20. The Mandate class carries no sourced_from relation, so the document is named here and on every Rule the mandate links to. What UPI calls this product, and how NPCI runs it, is not held.", "confidence": "high" }, "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 nothing here rests on UPI's own scheme rules.", "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": "in-upi:src.rbi-e-mandate-framework-2026", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the mandate's registration, validity, withdrawal, fixed or variable amount, pre and post transaction notice, opt-out and no-charge provisions." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "in-upi:role.beneficiary-bank", "id": "role.beneficiary-bank", "rail": "in-upi", "class": "Role", "name": "Beneficiary bank (the payee's bank)", "summary": "The bank holding the account a UPI payment is going to. When the payer's account has been debited and this bank cannot credit the payee on a funds transfer, the turn around time circular puts the automatic reversal on it, at the latest on the day after the transaction. It is the only party the Reserve Bank's UPI rows name.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-tat-circular-2019", "section": "Annex, row 4(a); general instructions 1 and 3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Reserve Bank of India documents read 2026-09-20, cited on the links.", "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. NPCI's own rules for UPI, which define UPI's own roles, are not public to Orca, so this record describes the party only as far as the regulator's texts go.", "source_edition": "RBI/2019-20/67 of 20 September 2019, Annex, read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-tat-circular-2019", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that the beneficiary bank must reverse a UPI funds transfer failure latest on the day after the transaction." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.auto-reversal", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:exc.auto-reversal", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.auto-reversal-funds-transfer-next-day", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.compensation-hundred-rupees-a-day", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.compensation-without-a-complaint", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.deadline-is-an-outer-limit", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:role.customer", "id": "role.customer", "rail": "in-upi", "class": "Role", "name": "Customer (the payer)", "summary": "The person or business whose account is debited. The Reserve Bank's framework is built around this party: a failure not attributable to them must be reversed and compensated without their asking, they may raise a dispute through the operator or through their own bank, they may take an unresolved grievance to an ombudsman, and their liability for a transaction they did not authorise is capped or nil depending on where the fault lay and how quickly they reported it.", "kind": "party", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-tat-circular-2019", "section": "Annex, general instruction 2; paragraph 5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-odr-circular-2020", "section": "Annex 3.2 and 5.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-customer-liability-circular-2017", "section": "paragraphs 6, 7 and 8", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Reserve Bank of India documents read 2026-09-20, cited on the links.", "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. NPCI's own rules for UPI, which define UPI's own roles, are not public to Orca, so this record describes the party only as far as the regulator's texts go.", "source_edition": "RBI/2019-20/67, RBI/2020-21/21 and RBI/2017-18/15, read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-tat-circular-2019", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that a failure not attributable to the customer must be reversed and compensated without the customer having to ask." }, { "source": "in-upi:src.rbi-odr-circular-2020", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that a customer may lodge a dispute through the operator or through their own participating institution." }, { "source": "in-upi:src.rbi-customer-liability-circular-2017", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the customer's liability caps depending on fault and reporting speed." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.odr-grievance", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:exc.ombudsman-complaint", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:exc.unauthorised-transaction-claim", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:mandate.upi-recurring", "type": "given_by", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.escalation-after-one-month", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.limited-liability-for-the-customer", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.ombudsman-when-a-complaint-may-be-filed", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:role.merchant", "id": "role.merchant", "rail": "in-upi", "class": "Role", "name": "Merchant (the payee in a payment for goods or services)", "summary": "The business a UPI customer pays. The Reserve Bank's turn around time circular separates a payment to a merchant from a transfer to another person and gives it the longer reversal clock: where the account was debited and no confirmation reached the merchant, the reversal runs to five days after the transaction rather than one. On a recurring mandate the pre-charge notice must name the merchant.", "kind": "party", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-tat-circular-2019", "section": "Annex, row 4(b)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-e-mandate-framework-2026", "section": "paragraphs 6(b) and 7", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Reserve Bank of India documents read 2026-09-20, cited on the links.", "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. NPCI's own rules for UPI, which define UPI's own roles, are not public to Orca, so this record describes the party only as far as the regulator's texts go.", "source_edition": "RBI/2019-20/67 Annex and RBI/DPSS/2026-27/396, read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-tat-circular-2019", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the separate five day reversal clock for a UPI payment to a merchant where no confirmation reached the merchant." }, { "source": "in-upi:src.rbi-e-mandate-framework-2026", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that the pre-transaction and post-transaction notices must name the merchant." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:mandate.upi-recurring", "type": "given_to", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.upi-autopay-modification", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.upi-autopay-pause-and-unpause", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.upi-autopay-revocation", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.upi-autopay-validity-and-expiry", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:role.npci", "id": "role.npci", "rail": "in-upi", "class": "Role", "name": "National Payments Corporation of India (NPCI)", "summary": "The authorised operator of UPI. The Reserve Bank's register of certificates of authorisation lists NPCI as a Retail Payments Organisation holding a certificate for Unified Payments Interface dated 24 August 2016, alongside separate certificates for the National Financial Switch, the Immediate Payment Service, RuPay affiliation, the National Automated Clearing House, the Aadhaar Enabled Payment System, cheque truncation and National Electronic Toll Collection. The Reserve Bank's own guidance on when a customer may go to an ombudsman defers to whatever period NPCI has set for that kind of complaint, so NPCI sets timelines a bank must meet. That NPCI also writes UPI's scheme rules and runs its clearing and settlement is an [Inference] from holding an authorisation to set up and operate the system; no NPCI document has been opened. None of it is public to Orca. The Reserve Bank's register footnotes that all approvals for NPCI's international activities moved to NPCI International Payments Limited with effect from 10 August 2020. Nothing published by NPCI itself is cited: www.npci.org.in answered a plain request with HTTP 403 on 2026-09-20, and its robots.txt answered the same way, so even its crawl policy could not be read.", "kind": "operator", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-certificates-of-authorisation-2026-09-08", "section": "Retail Payments Organisation, entry 1, Unified Payments Interface, 24.08.2016 and the footnote on international activities", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-payment-systems-overview", "section": "paragraph naming the systems NPCI operates", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-integrated-ombudsman-faq-2026", "section": "when a complaint may be filed before the ombudsman", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Reserve Bank of India documents read 2026-09-20, cited on the links.", "confidence": "high" }, "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. NPCI's own rules for UPI, which define UPI's own roles, are not public to Orca, so this record describes the party only as far as the regulator's texts go.", "source_edition": "RBI certificates of authorisation dated 8 September 2026, RBI payment systems overview page and the 2026 ombudsman questions and answers, read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-certificates-of-authorisation-2026-09-08", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms NPCI's Retail Payments Organisation entry with the Unified Payments Interface authorisation dated 24 August 2016 alongside its other certificates, and the footnote on international activities moving to NIPL on 10 August 2020." }, { "source": "in-upi:src.rbi-payment-systems-overview", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that NPCI operates UPI among the systems the Reserve Bank names it as running." }, { "source": "in-upi:src.rbi-integrated-ombudsman-faq-2026", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that a complaint before the ombudsman must wait 30 days or whatever longer period RBI, NPCI or a card network sets." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.odr-grievance", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.authentication-must-be-open-to-all-applications", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.dispute-lodging-channels-and-tracking", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.dispute-resolution-minimises-human-judgement", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.dispute-resolution-scope-and-compensation", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.finality-not-held", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.hours-not-held", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.interbank-dispute-rules-not-held", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.messages-not-held", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.npci-holds-the-upi-authorisation", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.operator-must-run-dispute-resolution", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.recall-not-held", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.refund-not-held", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.settlement-not-held", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.transaction-limits-not-held", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:role.payment-system-participant", "id": "role.payment-system-participant", "rail": "in-upi", "class": "Role", "name": "Payment System Participant (a member of an authorised payment system)", "summary": "A member of an authorised payment system, bank or non-bank. The online dispute resolution circular uses the abbreviation PSP for exactly this and for nothing else: the operator gives its participating members access to its dispute resolution system, and each participant gives its own customers a way in. Read any PSP in a Reserve Bank payment systems circular as this, not as the payment service provider bank that gives a UPI customer a handle. The two meanings of PSP are a real hazard on this rail. The Reserve Bank's own texts also write Payment System Provider in the Authentication Directions and the E-mandate Framework, a third phrase, which neither document defines.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-odr-circular-2020", "section": "paragraph 3; Annex 1.1, 3.1, 3.2 and 5.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-authentication-directions-2025", "section": "paragraphs 3, 4 and 7", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Reserve Bank of India documents read 2026-09-20, cited on the links.", "confidence": "high" }, "currency": { "effective_since": "2020-08-06", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from Reserve Bank of India material only. NPCI's own rules for UPI, which define UPI's own roles, are not public to Orca, so this record describes the party only as far as the regulator's texts go.", "source_edition": "RBI/2020-21/21 of 6 August 2020 and RBI/2025-26/79, read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-odr-circular-2020", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the ODR circular's own use of Payment System Participant, abbreviated PSP, for a member of an authorised payment system." }, { "source": "in-upi:src.rbi-authentication-directions-2025", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the applicability to Payment System Providers and Payment System Participants and the interoperability duty on those participants." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.odr-grievance", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.authentication-must-be-open-to-all-applications", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.bank-includes-non-banks", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.deadline-is-an-outer-limit", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.dispute-lodging-channels-and-tracking", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.dispute-resolution-minimises-human-judgement", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.dispute-resolution-scope-and-compensation", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.e-mandate-costs-the-customer-nothing", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.e-mandate-framework-covers-upi", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.operator-must-run-dispute-resolution", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.two-factors-of-authentication", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:role.payments-regulatory-board", "id": "role.payments-regulatory-board", "rail": "in-upi", "class": "Role", "name": "Payments Regulatory Board", "summary": "The board through which the Reserve Bank exercises its powers over payment systems under sub-sections 1 and 2 of section 3 of the Payment and Settlement Systems Act, 2007. Its membership is fixed by section 3(3): the Governor chairs it, the Deputy Governor and the Executive Director in charge of payment and settlement systems sit on it, the secretaries of the Department of Financial Services and of the Ministry of Electronics and Information Technology sit on it, and one further member is named. The Principal Legal Adviser attends as a permanent invitee under the Payments Regulatory Board Regulations, 2025. The membership and the invitee rule come from a live Reserve Bank page, not from the Act or the Regulations. The Payments Regulatory Board (Amendment) Regulations, 2025 are a PDF on rbidocs.rbi.org.in, which returned nothing on 2026-09-20, so the Regulations were not read and no clause of them is cited. [Unverified] whether the membership on the page is current.", "kind": "authority", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-payment-systems-overview", "section": "Payments Regulatory Board section and member table", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "in-upi:participants", "note": "The Reserve Bank's older overview page still calls the Board for Regulation and Supervision of Payment and Settlement Systems the highest policy making body, which contradicts this.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reserve Bank of India documents read 2026-09-20, cited on the links.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the page read does not say when the Payments Regulatory Board was constituted", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from Reserve Bank of India material only. NPCI's own rules for UPI, which define UPI's own roles, are not public to Orca, so this record describes the party only as far as the regulator's texts go.", "source_edition": "RBI payment systems overview page, live as read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-payment-systems-overview", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the Board's membership table under section 3(3) of the PSS Act and the Principal Legal Adviser's permanent invitee status under regulation 3(2) of the Payments Regulatory Board Regulations, 2025." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:rule.payments-regulatory-board-governs", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:role.rbi-ombudsman", "id": "role.rbi-ombudsman", "rail": "in-upi", "class": "Role", "name": "RBI Ombudsman", "summary": "An officer the Reserve Bank appoints to examine customer complaints of deficiency in service by a regulated entity, free of charge and outside the courts. A UPI customer reaches an ombudsman when the bank or operator has not resolved the grievance. The ombudsman may facilitate a settlement, pass an award directing the entity to act or to pay, or reject the complaint with reasons, and a deputy ombudsman assists and may close complaints to the extent the scheme allows. The scheme in force is now the 2026 one, which came into force on 1 July 2026 and replaced the 2021 scheme; the turn around time and dispute resolution circulars still send customers to the 2021 scheme. The scheme texts themselves are PDFs on rbidocs.rbi.org.in, which returned nothing on 2026-09-20, so everything here rests on the 2021 covering notification and the Reserve Bank's own 2026 questions and answers.", "kind": "authority", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-integrated-ombudsman-notification-2021", "section": "the notification as a whole", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-integrated-ombudsman-faq-2026", "section": "questions 4, 6, 22, 23 and 24", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Reserve Bank of India documents read 2026-09-20, cited on the links.", "confidence": "medium" }, "currency": { "effective_since": "2021-11-12", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from Reserve Bank of India material only. NPCI's own rules for UPI, which define UPI's own roles, are not public to Orca, so this record describes the party only as far as the regulator's texts go.", "source_edition": "RBI notification CEPD.PRD.No.S873/13.01.001/2021-22 and the RB-IOS 2026 questions and answers updated 1 July 2026, read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-integrated-ombudsman-notification-2021", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the 2021 scheme's commencement on 12 November 2021." }, { "source": "in-upi:src.rbi-integrated-ombudsman-faq-2026", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the ombudsman's function, the deputy ombudsman's role, the three outcomes of settlement, award or rejection, and the 2026 scheme's replacement of the 2021 scheme on 1 July 2026." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.ombudsman-complaint", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.ombudsman-costs-nothing-and-what-it-can-award", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.ombudsman-how-a-complaint-ends", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.ombudsman-when-a-complaint-may-be-filed", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:role.rbi", "id": "role.rbi", "rail": "in-upi", "class": "Role", "name": "Reserve Bank of India", "summary": "India's central bank and, under the Payment and Settlement Systems Act, 2007, the designated authority for regulating and supervising payment systems. Nobody else may run a payment system in India without its authorisation. It authorised UPI, sets the deadlines for reversing a failed payment and the compensation for missing them, requires an online dispute resolution system, sets the rules on authentication, on recurring mandates and on who bears the loss of an unauthorised transaction, and appoints the ombudsmen who hear customers whose grievances are not resolved. Its Department of Payment and Settlement Systems issues the circulars and serves as secretariat to the board that governs. The Payment and Settlement Systems Act, 2007 and the Payment and Settlement Systems Regulations, 2008 came into effect on 12 August 2008, as both Reserve Bank overview pages state. The Act text itself was not read: the India Code copy did not answer within 45 seconds on 2026-09-20 and the Reserve Bank's own copy is on a document host that returned nothing.", "kind": "authority", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-payment-systems-overview", "section": "legal frame and authorisation", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-payment-and-settlement-systems-page", "section": "Board for Regulation and Supervision paragraph; Payment and Settlement Systems Act paragraph", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-tat-circular-2019", "section": "addressee and paragraph 7", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Reserve Bank of India documents read 2026-09-20, cited on the links.", "confidence": "high" }, "currency": { "effective_since": "2008-08-12", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from Reserve Bank of India material only. NPCI's own rules for UPI, which define UPI's own roles, are not public to Orca, so this record describes the party only as far as the regulator's texts go.", "source_edition": "RBI payment systems overview pages and RBI/2019-20/67, read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-payment-and-settlement-systems-page", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the Reserve Bank as designated authority for regulating payment systems and the 12 August 2008 commencement of the PSS Act and its 2008 regulations." }, { "source": "in-upi:src.rbi-tat-circular-2019", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the Reserve Bank's Department of Payment and Settlement Systems as the issuer of the circular and that the term bank applies to non-banks wherever authorised." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:rule.authorisation-is-required-to-run-a-payment-system", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.ombudsman-scheme-2021-covers-system-participants", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.ombudsman-scheme-2026-replaced-2021", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.payments-regulatory-board-governs", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:role.remitter-bank", "id": "role.remitter-bank", "rail": "in-upi", "class": "Role", "name": "Remitter bank (the payer's bank)", "summary": "The bank holding the account a UPI payment is made from. The Reserve Bank's texts call this party several things: the turn around time circular writes remitter and originator and says these terms carry their ordinary banking meaning, the Authentication Directions define the issuer as the bank or non-bank that maintains the customer's account from which payment is made, and the customer liability circular simply writes the bank. It owes the customer the authentication rules, the pre-charge and post-charge notices on a recurring mandate, the ten working day credit after an unauthorised transaction is reported, and the proof that the customer is liable at all. That the issuer of the Authentication Directions and the E-mandate Framework is the payer's bank on a UPI payment is an [Inference] from the definition, which turns on holding the account the payment is made from. Neither document names UPI when it defines the issuer. The term in UPI's own vocabulary, the payment service provider bank that gives a customer a UPI handle, appears in no Reserve Bank document read and is not held here.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-tat-circular-2019", "section": "Annex, general instructions 3 and 5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-authentication-directions-2025", "section": "paragraph 5, definition of issuer", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-customer-liability-circular-2017", "section": "paragraphs 5, 9 and 12", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Reserve Bank of India documents read 2026-09-20, cited on the links.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the documents read define the party without dating the definition", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from Reserve Bank of India material only. NPCI's own rules for UPI, which define UPI's own roles, are not public to Orca, so this record describes the party only as far as the regulator's texts go.", "source_edition": "RBI/2019-20/67, RBI/2025-26/79 and RBI/2017-18/15, read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-tat-circular-2019", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the terms remitter and originator carry their ordinary banking meaning." }, { "source": "in-upi:src.rbi-authentication-directions-2025", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the definition of issuer as the bank or non-bank that maintains the customer's account from which payment is made." }, { "source": "in-upi:src.rbi-customer-liability-circular-2017", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the bank's alert, ten day credit and burden of proof duties toward the customer." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.unauthorised-transaction-claim", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.alerts-and-channels-for-reporting", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.bank-must-prove-the-customer-is-liable", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.claim-settled-within-ninety-days", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.compensation-without-a-complaint", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.deadline-is-an-outer-limit", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.e-mandate-authentication-threshold", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.e-mandate-costs-the-customer-nothing", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.e-mandate-disputes-and-liability", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.e-mandate-first-charge", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.e-mandate-framework-covers-upi", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.e-mandate-higher-threshold-for-three-categories", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.e-mandate-notice-after-each-charge", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.e-mandate-notice-before-each-charge", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.e-mandate-registration-and-withdrawal", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.issuer-pays-in-full-for-bad-authentication", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.limited-liability-for-the-customer", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.money-back-within-ten-working-days", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.risk-based-checks-above-the-minimum", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.transaction-day-and-reversal-day", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.two-factors-of-authentication", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.upi-autopay-every-mandate-event-is-notified", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.upi-autopay-modification", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.upi-autopay-pause-and-unpause", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.upi-autopay-revocation", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.upi-autopay-validity-and-expiry", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.zero-liability-for-the-customer", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:role.third-party-app-provider", "id": "role.third-party-app-provider", "rail": "in-upi", "class": "Role", "name": "Third party application provider (TPAP)", "summary": "The provider of a mobile application a customer pays with on UPI, where that provider is not the customer's own bank. The Reserve Bank's online dispute resolution circular names third party app providers, and UPI as the case they arise in, and requires them to let a customer raise a dispute in the same app they paid in, wired into the operator's dispute resolution system. The Reserve Bank does not authorise them: no such category appears in its register of certificates of authorisation. What a third party application provider may do, how it is admitted and which bank sponsors it are NPCI's rules and are not held. The register of certificates of authorisation does list the corporate groups behind the best known UPI apps, but for other businesses: as bill payment operating units, prepaid instrument issuers and payment aggregators, never for UPI.", "kind": "service_provider", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-odr-circular-2020", "section": "Annex 5.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-certificates-of-authorisation-2026-09-08", "section": "the register as a whole; no third party application provider category appears in it", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reserve Bank of India documents read 2026-09-20, cited on the links.", "confidence": "high" }, "currency": { "effective_since": "2020-08-06", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from Reserve Bank of India material only. NPCI's own rules for UPI, which define UPI's own roles, are not public to Orca, so this record describes the party only as far as the regulator's texts go.", "source_edition": "RBI/2020-21/21 Annex and the RBI certificates of authorisation dated 8 September 2026, read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-odr-circular-2020", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that third party app providers on mobile systems such as UPI must let a customer raise a dispute in the app they paid in, wired into the operator's dispute resolution system." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:rule.no-upi-app-is-authorised-by-the-reserve-bank", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.tpap-in-app-dispute-lodging", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.upi-autopay-every-mandate-event-is-notified", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.upi-autopay-pause-and-unpause", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.upi-autopay-revocation", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.alerts-and-channels-for-reporting", "id": "rule.alerts-and-channels-for-reporting", "rail": "in-upi", "class": "Rule", "name": "Alerts the customer must get, and the ways they must be able to report", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-customer-liability-circular-2017", "section": "paragraph 5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.remitter-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "in-upi:exc.unauthorised-transaction-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RBI/2017-18/15, paragraph 5, read 2026-09-20.", "confidence": "high" }, "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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI/2017-18/15, DBR.No.Leg.BC.78/09.07.005/2017-18, dated 6 July 2017; page and Annex read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-customer-liability-circular-2017", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the mandatory SMS alert registration, the 24x7 multi channel reporting requirement, the reply-to-alert facility, the acknowledgement and complaint number, and the record of alert delivery and response timing." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.unauthorised-transaction-claim", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.authentication-exemptions-include-upi-tap-and-pay", "id": "rule.authentication-exemptions-include-upi-tap-and-pay", "rail": "in-upi", "class": "Rule", "name": "Which payments are exempt from two factor authentication, including a UPI tap and pay", "statement": "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.", "rests_on": "rule", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-authentication-directions-2025", "section": "Annexure-1, items 1 to 7, in particular items 2 and 7", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "applies_to", "to": "in-upi:txn.merchant-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "in-upi:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RBI/2025-26/79, Annexure-1, read 2026-09-20. The Reserve Bank letter of 2 September 2026 that exempts UPI tap and pay is named in the annexure and was not itself read; what it does beyond creating the exemption is [Unverified].", "confidence": "high" }, "currency": { "effective_since": "2026-04-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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI/2025-26/79, CO.DPSS.POLC.No. S 668/02-14-015/2025-2026, dated 25 September 2025; page and both Annexures read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-authentication-directions-2025", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms Annexure-1's exemption list, including UPI tap and pay on NFC point of sale machines under the 2 September 2026 letter to NPCI, and recurring e-mandate payments after the first." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "in-upi:rule.authentication-must-be-open-to-all-applications", "id": "rule.authentication-must-be-open-to-all-applications", "rail": "in-upi", "class": "Rule", "name": "An authentication or tokenisation service must be open to everything in its environment", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-authentication-directions-2025", "section": "paragraph 7", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.payment-system-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.npci", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RBI/2025-26/79, paragraph 7, read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2026-04-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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI/2025-26/79, CO.DPSS.POLC.No. S 668/02-14-015/2025-2026, dated 25 September 2025; page and both Annexures read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-authentication-directions-2025", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the interoperability and open access requirement across every application, token requestor, use case, channel and token storage mechanism in the operating environment." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "in-upi:rule.authorisation-is-required-to-run-a-payment-system", "id": "rule.authorisation-is-required-to-run-a-payment-system", "rail": "in-upi", "class": "Rule", "name": "Nobody may run a payment system in India without the Reserve Bank's authorisation", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-payment-systems-overview", "section": "legal frame paragraph", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-payment-and-settlement-systems-page", "section": "Payment and Settlement Systems Act paragraph", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-certificates-of-authorisation-2026-09-08", "section": "opening paragraphs", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.rbi", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The Reserve Bank's two payment systems overview pages and the opening of its certificates of authorisation register, read 2026-09-20. The Act text itself was not read: the India Code copy did not answer within 45 seconds and the Reserve Bank's own copy is on a document host that returned nothing, so the section is cited as the Reserve Bank states it.", "confidence": "medium" }, "currency": { "effective_since": "2008-08-12", "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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI certificates of authorisation dated 8 September 2026 and the RBI payment systems overview pages; read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-payment-and-settlement-systems-page", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms section 4 of the PSS Act 2007, and that the Act and 2008 regulations came into effect on 12 August 2008." }, { "source": "in-upi:src.rbi-certificates-of-authorisation-2026-09-08", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that the Reserve Bank publishes the register of everyone it has authorised under the PSS Act." }, { "source": "in-upi:src.rbi-payment-systems-overview", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms section 4 of the PSS Act again on the newer overview page." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "in-upi:rule.auto-reversal-funds-transfer-next-day", "id": "rule.auto-reversal-funds-transfer-next-day", "rail": "in-upi", "class": "Rule", "name": "UPI funds transfer: automatic reversal at the latest on the day after the transaction", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-tat-circular-2019", "section": "Annex, row 4(a); general instructions 1, 2 and 4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.beneficiary-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "in-upi:txn.funds-transfer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "in-upi:exc.auto-reversal", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RBI/2019-20/67, Annex row 4(a) with general instructions 1, 2 and 4, read 2026-09-20 and restated in Orca's own words.", "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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI/2019-20/67, DPSS.CO.PD No.629/02.01.014/2019-20, dated 20 September 2019, in effect from 15 October 2019; page read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-tat-circular-2019", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the UPI funds transfer row: auto reversal by the beneficiary bank latest on T plus 1 day where the account is debited but the beneficiary account is not credited, and that T is the calendar date of the transaction." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.auto-reversal", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.auto-reversal-merchant-payment-five-days", "id": "rule.auto-reversal-merchant-payment-five-days", "rail": "in-upi", "class": "Rule", "name": "UPI payment to a merchant: automatic reversal within five days of the transaction", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-tat-circular-2019", "section": "Annex, row 4(b); general instructions 1 and 4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "applies_to", "to": "in-upi:txn.merchant-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "in-upi:exc.auto-reversal", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RBI/2019-20/67, Annex row 4(b) with general instructions 1 and 4, read 2026-09-20. That the duty falls on the payee's side is an [Inference] from general instruction 1; row 4(b) names no party, so no binds link is written.", "confidence": "medium" }, "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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI/2019-20/67, DPSS.CO.PD No.629/02.01.014/2019-20, dated 20 September 2019, in effect from 15 October 2019; page read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-tat-circular-2019", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the UPI merchant payment row: auto reversal within T plus 5 days where the account is debited but no transaction confirmation reached the merchant location, with no bank named in that row." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.auto-reversal", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.bank-includes-non-banks", "id": "rule.bank-includes-non-banks", "rail": "in-upi", "class": "Rule", "name": "Bank in the framework includes a non-bank that is authorised", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-tat-circular-2019", "section": "Annex, general instruction 6; addressee line", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.payment-system-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RBI/2019-20/67, Annex general instruction 6 and the addressee line, read 2026-09-20.", "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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI/2019-20/67, DPSS.CO.PD No.629/02.01.014/2019-20, dated 20 September 2019, in effect from 15 October 2019; page read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-tat-circular-2019", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that the term bank includes non-banks wherever authorised, and that the circular addresses all operators and participants of authorised payment systems." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "in-upi:rule.bank-must-prove-the-customer-is-liable", "id": "rule.bank-must-prove-the-customer-is-liable", "rail": "in-upi", "class": "Rule", "name": "The bank has to prove the customer is liable", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-customer-liability-circular-2017", "section": "paragraph 12", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.remitter-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "in-upi:exc.unauthorised-transaction-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RBI/2017-18/15, paragraph 12, read 2026-09-20.", "confidence": "high" }, "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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI/2017-18/15, DBR.No.Leg.BC.78/09.07.005/2017-18, dated 6 July 2017; page and Annex read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-customer-liability-circular-2017", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that the burden of proving customer liability in an unauthorised transaction lies on the bank." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.unauthorised-transaction-claim", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.claim-settled-within-ninety-days", "id": "rule.claim-settled-within-ninety-days", "rail": "in-upi", "class": "Rule", "name": "The claim is settled within ninety days, or the customer is paid anyway", "statement": "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.", "rests_on": "rule", "facet": "liability", "parameters": { "time_window": { "count": 90, "unit": "calendar_day", "from": "receipt", "text": "ninety days from the bank receiving the complaint" } }, "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-customer-liability-circular-2017", "section": "paragraph 10", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.remitter-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "in-upi:exc.unauthorised-transaction-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RBI/2017-18/15, paragraph 10, read 2026-09-20.", "confidence": "high" }, "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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI/2017-18/15, DBR.No.Leg.BC.78/09.07.005/2017-18, dated 6 July 2017; page and Annex read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-customer-liability-circular-2017", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the 90 day outer limit for resolving a complaint and establishing liability, the fallback compensation if that deadline is missed, and the no lost interest protections." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.unauthorised-transaction-claim", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.compensation-hundred-rupees-a-day", "id": "rule.compensation-hundred-rupees-a-day", "rail": "in-upi", "class": "Rule", "name": "Compensation of 100 rupees for each day of delay beyond the deadline", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-tat-circular-2019", "section": "Annex, rows 4(a) and 4(b); row 1(a) for the wording on crediting the account holder", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.beneficiary-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "in-upi:txn.funds-transfer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "in-upi:txn.merchant-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "in-upi:exc.auto-reversal", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RBI/2019-20/67, Annex rows 4(a) and 4(b), read 2026-09-20. The amount is untyped because the schema's limit parameter describes a ceiling per entry, batch, file or day, and this is a penalty that accumulates.", "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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI/2019-20/67, DPSS.CO.PD No.629/02.01.014/2019-20, dated 20 September 2019, in effect from 15 October 2019; page read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-tat-circular-2019", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the 100 rupee per day compensation rate on both UPI rows, accruing from the day after the deadline passes." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.auto-reversal", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.compensation-without-a-complaint", "id": "rule.compensation-without-a-complaint", "rail": "in-upi", "class": "Rule", "name": "Compensation is credited without waiting for the customer to complain", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-tat-circular-2019", "section": "paragraph 5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.remitter-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.beneficiary-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "in-upi:exc.auto-reversal", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RBI/2019-20/67, paragraph 5, read 2026-09-20.", "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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI/2019-20/67, DPSS.CO.PD No.629/02.01.014/2019-20, dated 20 September 2019, in effect from 15 October 2019; page read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-tat-circular-2019", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that compensation is credited to the customer's account suo moto, without waiting for a complaint or claim." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.auto-reversal", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.deadline-is-an-outer-limit", "id": "rule.deadline-is-an-outer-limit", "rail": "in-upi", "class": "Rule", "name": "The stated deadline is an outer limit, not a target", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-tat-circular-2019", "section": "paragraph 4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.remitter-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.beneficiary-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.payment-system-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RBI/2019-20/67, paragraph 4, read 2026-09-20.", "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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI/2019-20/67, DPSS.CO.PD No.629/02.01.014/2019-20, dated 20 September 2019, in effect from 15 October 2019; page read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-tat-circular-2019", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that the prescribed turn around time is the outer limit for resolution and that operators and participants should endeavour towards quicker resolution." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.auto-reversal", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.dispute-lodging-channels-and-tracking", "id": "rule.dispute-lodging-channels-and-tracking", "rail": "in-upi", "class": "Rule", "name": "How a customer lodges a dispute and follows it", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-odr-circular-2020", "section": "Annex 5.1, 5.3 and 5.4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.npci", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.payment-system-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "in-upi:exc.odr-grievance", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "in-upi:rule.tpap-in-app-dispute-lodging", "note": "The narrower case of this duty. That record is Annex 5.2, the duty on a third party application provider to carry dispute lodging inside the app the payment was made in; this one is Annex 5.1, 5.3 and 5.4, the general duty on the operator and the customer's own institution.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RBI/2020-21/21, Annex 5.1, 5.3 and 5.4, read 2026-09-20.", "confidence": "high" }, "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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI/2020-21/21, DPSS.CO.PD No.116/02.12.004/2020-21, dated 6 August 2020; page read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-odr-circular-2020", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the required lodging channels, the simple minimum-detail process, and the unique reference number for tracking a dispute." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.odr-grievance", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.tpap-in-app-dispute-lodging", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.dispute-resolution-minimises-human-judgement", "id": "rule.dispute-resolution-minimises-human-judgement", "rail": "in-upi", "class": "Rule", "name": "The dispute resolution system is rule driven, with as little human judgement as possible", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-odr-circular-2020", "section": "Annex 2.1; paragraph 1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.npci", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.payment-system-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "in-upi:exc.odr-grievance", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RBI/2020-21/21, Annex 2.1 and paragraph 1, read 2026-09-20. The second sentence is Orca's reading of what the requirement implies, which is why the record 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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI/2020-21/21, DPSS.CO.PD No.116/02.12.004/2020-21, dated 6 August 2020; page read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-odr-circular-2020", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that the ODR system must be transparent, rule based, system driven and unbiased, with zero or minimal manual intervention." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.odr-grievance", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.dispute-resolution-scope-and-compensation", "id": "rule.dispute-resolution-scope-and-compensation", "rail": "in-upi", "class": "Rule", "name": "The dispute resolution system covers the failed transactions the turn around time framework lists", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-odr-circular-2020", "section": "Annex 4.1 and 4.2; paragraph 4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-tat-circular-2019", "section": "Annex, rows 4(a) and 4(b)", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.npci", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.payment-system-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "in-upi:txn.funds-transfer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "in-upi:txn.merchant-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "in-upi:exc.odr-grievance", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RBI/2020-21/21 Annex 4.1 and 4.2 and paragraph 4, with RBI/2019-20/67 Annex rows 4(a) and 4(b), read 2026-09-20.", "confidence": "high" }, "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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI/2020-21/21, DPSS.CO.PD No.116/02.12.004/2020-21, dated 6 August 2020; page read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-odr-circular-2020", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that the ODR system's initial scope is the failed transactions named in the turn around time circular, and that circular's compensation provisions must be honoured while resolving disputes through it." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.odr-grievance", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.e-mandate-authentication-threshold", "id": "rule.e-mandate-authentication-threshold", "rail": "in-upi", "class": "Rule", "name": "Recurring payments up to 15,000 rupees need no fresh authentication", "statement": "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.", "rests_on": "rule", "facet": "limits", "parameters": { "limit": { "amount": 15000, "currency": "INR", "per": "entry", "text": "15,000 rupees per recurring transaction without an additional factor of authentication" } }, "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-e-mandate-framework-2026", "section": "paragraph 8(a)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.remitter-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "in-upi:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RBI/DPSS/2026-27/396, paragraph 8(a), read 2026-09-20. effective_since is the date of the directions, which took effect immediately; it is not the date this threshold first applied, because the directions consolidate earlier circulars that were not read.", "confidence": "high" }, "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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI/DPSS/2026-27/396, RBI/CO.DPSS.POLC.No.S56/02.14.003/2026-27, dated 21 April 2026; page read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-e-mandate-framework-2026", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the 15,000 rupee per transaction threshold below which a recurring payment needs no additional factor of authentication." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:mandate.upi-recurring", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.e-mandate-costs-the-customer-nothing", "id": "rule.e-mandate-costs-the-customer-nothing", "rail": "in-upi", "class": "Rule", "name": "A recurring mandate costs the customer nothing, and the acquirer answers for its merchants", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-e-mandate-framework-2026", "section": "paragraph 10", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.remitter-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.payment-system-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "in-upi:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RBI/DPSS/2026-27/396, paragraph 10, read 2026-09-20.", "confidence": "high" }, "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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI/DPSS/2026-27/396, RBI/CO.DPSS.POLC.No.S56/02.14.003/2026-27, dated 21 April 2026; page read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-e-mandate-framework-2026", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms no charge for the mandate facility, portability of a card mandate to a reissued card, and the acquirer's duty to ensure merchant compliance." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:mandate.upi-recurring", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.e-mandate-disputes-and-liability", "id": "rule.e-mandate-disputes-and-liability", "rail": "in-upi", "class": "Rule", "name": "Disputes on a recurring payment, and who bears an unauthorised one", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-e-mandate-framework-2026", "section": "paragraph 9", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-customer-liability-circular-2017", "section": "paragraphs 6 to 9", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.remitter-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "in-upi:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "in-upi:exc.unauthorised-transaction-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RBI/DPSS/2026-27/396, paragraph 9, read with RBI/2017-18/15 paragraphs 6 to 9, read 2026-09-20.", "confidence": "high" }, "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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI/DPSS/2026-27/396, RBI/CO.DPSS.POLC.No.S56/02.14.003/2026-27, dated 21 April 2026; page read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-e-mandate-framework-2026", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the issuer's dispute redressal duty and that the customer liability instructions apply to recurring transactions under a mandate." }, { "source": "in-upi:src.rbi-customer-liability-circular-2017", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the zero and limited liability rules that the e-mandate framework extends to recurring transactions." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.unauthorised-transaction-claim", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.e-mandate-first-charge", "id": "rule.e-mandate-first-charge", "rail": "in-upi", "class": "Rule", "name": "The first charge under a mandate is authenticated", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-e-mandate-framework-2026", "section": "paragraph 5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.remitter-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "in-upi:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RBI/DPSS/2026-27/396, paragraph 5, read 2026-09-20.", "confidence": "high" }, "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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI/DPSS/2026-27/396, RBI/CO.DPSS.POLC.No.S56/02.14.003/2026-27, dated 21 April 2026; page read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-e-mandate-framework-2026", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the AFA requirement on the first mandate transaction, the combined authentication option, and that mandate payments are not subject to other customer set limits." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:mandate.upi-recurring", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:state.e-mandate-registered", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.e-mandate-framework-covers-upi", "id": "rule.e-mandate-framework-covers-upi", "rail": "in-upi", "class": "Rule", "name": "The recurring payment framework covers UPI", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-e-mandate-framework-2026", "section": "paragraphs 1 and 2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.remitter-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.payment-system-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "in-upi:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RBI/DPSS/2026-27/396, paragraphs 1 and 2, read 2026-09-20.", "confidence": "high" }, "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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI/DPSS/2026-27/396, RBI/CO.DPSS.POLC.No.S56/02.14.003/2026-27, dated 21 April 2026; page read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-e-mandate-framework-2026", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that the applicability paragraph binds every payment system provider and participant for recurring transactions using cards, PPI or UPI, domestic or cross-border." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:mandate.upi-recurring", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.e-mandate-higher-threshold-for-three-categories", "id": "rule.e-mandate-higher-threshold-for-three-categories", "rail": "in-upi", "class": "Rule", "name": "Three kinds of recurring payment have a 1,00,000 rupee threshold instead", "statement": "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.", "rests_on": "rule", "facet": "limits", "parameters": { "limit": { "amount": 100000, "currency": "INR", "per": "entry", "text": "1,00,000 rupees per transaction for insurance premiums, mutual fund subscriptions and credit card bill payments" } }, "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-e-mandate-framework-2026", "section": "paragraph 8(b)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.remitter-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "in-upi:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RBI/DPSS/2026-27/396, paragraph 8(b), read 2026-09-20. 1,00,000 in Indian numbering is one hundred thousand rupees. effective_since is the date of the directions, not the date the threshold first applied.", "confidence": "high" }, "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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI/DPSS/2026-27/396, RBI/CO.DPSS.POLC.No.S56/02.14.003/2026-27, dated 21 April 2026; page read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-e-mandate-framework-2026", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the 1,00,000 rupee threshold for insurance premium, mutual fund subscription and credit card bill payments." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:mandate.upi-recurring", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.e-mandate-notice-after-each-charge", "id": "rule.e-mandate-notice-after-each-charge", "rail": "in-upi", "class": "Rule", "name": "The customer is told after each recurring charge", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-e-mandate-framework-2026", "section": "paragraph 7", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.remitter-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "in-upi:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RBI/DPSS/2026-27/396, paragraph 7, read 2026-09-20.", "confidence": "high" }, "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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI/DPSS/2026-27/396, RBI/CO.DPSS.POLC.No.S56/02.14.003/2026-27, dated 21 April 2026; page read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-e-mandate-framework-2026", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the post-transaction notification's minimum content, including grievance redressal details." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:mandate.upi-recurring", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.e-mandate-notice-before-each-charge", "id": "rule.e-mandate-notice-before-each-charge", "rail": "in-upi", "class": "Rule", "name": "The customer is told at least a day before each recurring charge", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-e-mandate-framework-2026", "section": "paragraph 6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.remitter-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "in-upi:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RBI/DPSS/2026-27/396, paragraph 6, read 2026-09-20. The twenty four hours is untyped: the schema's window anchors count forward from an event, and this is a period of notice that must fall before one.", "confidence": "high" }, "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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI/DPSS/2026-27/396, RBI/CO.DPSS.POLC.No.S56/02.14.003/2026-27, dated 21 April 2026; page read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-e-mandate-framework-2026", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the 24 hour pre-transaction notice, its minimum content, the AFA-confirmed opt-out, and the FASTag and NCMC exemption." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:mandate.upi-recurring", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:state.e-mandate-registered", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:state.e-mandate-withdrawn", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.e-mandate-registration-and-withdrawal", "id": "rule.e-mandate-registration-and-withdrawal", "rail": "in-upi", "class": "Rule", "name": "Registering a recurring mandate, and getting out of one", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-e-mandate-framework-2026", "section": "paragraph 4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.remitter-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "in-upi:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RBI/DPSS/2026-27/396, paragraph 4, read 2026-09-20.", "confidence": "high" }, "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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI/DPSS/2026-27/396, RBI/CO.DPSS.POLC.No.S56/02.14.003/2026-27, dated 21 April 2026; page read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-e-mandate-framework-2026", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the one-time AFA-validated registration, the validity period and modification or withdrawal facility, the fixed or capped variable amount options, the customer's choice of notification channel, and the AFA requirement to change or withdraw a mandate." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:mandate.upi-recurring", "type": "evidenced_by", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:mandate.upi-recurring", "type": "revoked_via", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:state.e-mandate-registered", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:state.e-mandate-withdrawn", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.escalation-after-one-month", "id": "rule.escalation-after-one-month", "rail": "in-upi", "class": "Rule", "name": "A grievance still unresolved after a month goes to an ombudsman", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-odr-circular-2020", "section": "paragraph 4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-tat-circular-2019", "section": "paragraph 6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.customer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "in-upi:exc.ombudsman-complaint", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RBI/2020-21/21 paragraph 4 and RBI/2019-20/67 paragraph 6, read 2026-09-20. Both pages name the 2021 scheme, which the Reserve Bank replaced on 1 July 2026; the 2026 scheme sets the waiting period differently, so read this rule together with the rule on when a complaint may be filed.", "confidence": "high" }, "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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI/2020-21/21, DPSS.CO.PD No.116/02.12.004/2020-21, dated 6 August 2020; page read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-odr-circular-2020", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that a grievance unresolved for one month may be taken to the Reserve Bank Integrated Ombudsman Scheme, 2021, as the ODR circular's paragraph 4 states it." }, { "source": "in-upi:src.rbi-tat-circular-2019", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the same escalation route in the turn around time circular's paragraph 6." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.ombudsman-complaint", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.finality-not-held", "id": "rule.finality-not-held", "rail": "in-upi", "class": "Rule", "name": "When a UPI payment becomes final is not held", "statement": "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.", "rests_on": "guidance", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-certificates-of-authorisation-2026-09-08", "section": "Retail Payments Organisation, entry 1, Unified Payments Interface, 24.08.2016", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-payment-systems-overview", "section": "paragraph naming the systems NPCI operates", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.npci", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "That NPCI operates UPI and writes its rules rests on the RBI certificates of authorisation dated 8 September 2026 and the RBI payment systems overview page, read 2026-09-20. That the documents are not readable rests on a plain request to www.npci.org.in on 2026-09-20, which returned HTTP 403, as did a request for its robots.txt. The record asserts nothing about what the rules say.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-20", "effective_to": null, "effective_note": "Drafted 2026-09-20. The record 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": "RBI certificates of authorisation dated 8 September 2026 and the RBI payment systems overview pages; read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-certificates-of-authorisation-2026-09-08", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms NPCI as the authorised operator of UPI, from which the record's claim that UPI's own rules are NPCI's follows; the record asserts nothing about what those rules say." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "in-upi:rule.framework-covers-domestic-transactions", "id": "rule.framework-covers-domestic-transactions", "rail": "in-upi", "class": "Rule", "name": "The framework covers payments that begin and end in India", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-tat-circular-2019", "section": "Annex, general instruction 7", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "RBI/2019-20/67, Annex general instruction 7, read 2026-09-20.", "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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI/2019-20/67, DPSS.CO.PD No.629/02.01.014/2019-20, dated 20 September 2019, in effect from 15 October 2019; page read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-tat-circular-2019", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that the framework covers domestic transactions where both originator and beneficiary are within India." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "in-upi:rule.hours-not-held", "id": "rule.hours-not-held", "rail": "in-upi", "class": "Rule", "name": "UPI's operating hours and cut-offs are not held", "statement": "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.", "rests_on": "guidance", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-certificates-of-authorisation-2026-09-08", "section": "Retail Payments Organisation, entry 1, Unified Payments Interface, 24.08.2016", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-payment-systems-overview", "section": "paragraph naming the systems NPCI operates", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.npci", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "That NPCI operates UPI and writes its rules rests on the RBI certificates of authorisation dated 8 September 2026 and the RBI payment systems overview page, read 2026-09-20. That the documents are not readable rests on a plain request to www.npci.org.in on 2026-09-20, which returned HTTP 403, as did a request for its robots.txt. The record asserts nothing about what the rules say.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-20", "effective_to": null, "effective_note": "Drafted 2026-09-20. The record 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": "RBI certificates of authorisation dated 8 September 2026 and the RBI payment systems overview pages; read 2026-09-20", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "in-upi:rule.interbank-dispute-rules-not-held", "id": "rule.interbank-dispute-rules-not-held", "rail": "in-upi", "class": "Rule", "name": "The rules banks use to settle a UPI dispute between themselves are not held", "statement": "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.", "rests_on": "guidance", "facet": "return", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-certificates-of-authorisation-2026-09-08", "section": "Retail Payments Organisation, entry 1, Unified Payments Interface, 24.08.2016", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-payment-systems-overview", "section": "paragraph naming the systems NPCI operates", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-integrated-ombudsman-faq-2026", "section": "question 17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.npci", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "That NPCI operates UPI and writes its rules rests on the RBI certificates of authorisation dated 8 September 2026 and the RBI payment systems overview page, read 2026-09-20, and on the Reserve Bank's 2026 ombudsman questions and answers, question 17, which defers to NPCI's own timelines. That the documents are not readable rests on a plain request to www.npci.org.in on 2026-09-20, which returned HTTP 403, as did a request for its robots.txt. The record asserts nothing about what the rules say.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-20", "effective_to": null, "effective_note": "Drafted 2026-09-20. The record 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": "RBI certificates of authorisation dated 8 September 2026 and the RBI payment systems overview pages; read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-certificates-of-authorisation-2026-09-08", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms NPCI as the authorised operator of UPI; the record asserts nothing about interbank dispute mechanics." }, { "source": "in-upi:src.rbi-integrated-ombudsman-faq-2026", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that the ombudsman's own 30 day wait defers to whatever longer period NPCI or a card network sets." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "in-upi:rule.issuer-pays-in-full-for-bad-authentication", "id": "rule.issuer-pays-in-full-for-bad-authentication", "rail": "in-upi", "class": "Rule", "name": "An issuer that authenticates against the rules pays the whole loss", "statement": "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.", "rests_on": "rule", "facet": "liability", "parameters": { "liability_holder": { "role": "in-upi:role.remitter-bank", "condition": "the payment was effected without complying with the authentication directions", "text": "the issuer compensates the customer for the loss in full" } }, "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-authentication-directions-2025", "section": "paragraph 9", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.remitter-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "in-upi:exc.unauthorised-transaction-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RBI/2025-26/79, paragraph 9, read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2026-04-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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI/2025-26/79, CO.DPSS.POLC.No. S 668/02-14-015/2025-2026, dated 25 September 2025; page and both Annexures read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-authentication-directions-2025", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that an issuer must ensure the robustness of its authentication mechanism, compensate the customer in full without demur for a loss from non-compliant authentication, and comply with the Digital Personal Data Protection Act 2023." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.unauthorised-transaction-claim", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.limited-liability-for-the-customer", "id": "rule.limited-liability-for-the-customer", "rail": "in-upi", "class": "Rule", "name": "When the customer bears part of the loss, and how much", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-customer-liability-circular-2017", "section": "paragraphs 7 and 8, with Tables 1 and 2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.customer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.remitter-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "in-upi:exc.unauthorised-transaction-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RBI/2017-18/15, paragraphs 7 and 8 with its two tables, read 2026-09-20 and restated in Orca's own grouping rather than the table's order. That this reaches a UPI payment is an [Inference] from the circular's category of remote payment transactions. A lakh is one hundred thousand rupees.", "confidence": "high" }, "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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI/2017-18/15, DBR.No.Leg.BC.78/09.07.005/2017-18, dated 6 July 2017; page and Annex read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-customer-liability-circular-2017", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the negligence rule, the four to seven working day liability ceilings by account type, and the board approved policy for delay beyond seven working days." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.unauthorised-transaction-claim", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.messages-not-held", "id": "rule.messages-not-held", "rail": "in-upi", "class": "Rule", "name": "UPI's message standard, fields and response codes are not held", "statement": "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.", "rests_on": "guidance", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-certificates-of-authorisation-2026-09-08", "section": "Retail Payments Organisation, entry 1, Unified Payments Interface, 24.08.2016", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-payment-systems-overview", "section": "paragraph naming the systems NPCI operates", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.npci", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "That NPCI operates UPI and writes its rules rests on the RBI certificates of authorisation dated 8 September 2026 and the RBI payment systems overview page, read 2026-09-20. That the documents are not readable rests on a plain request to www.npci.org.in on 2026-09-20, which returned HTTP 403, as did a request for its robots.txt. The record asserts nothing about what the rules say.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-20", "effective_to": null, "effective_note": "Drafted 2026-09-20. The record 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": "RBI certificates of authorisation dated 8 September 2026 and the RBI payment systems overview pages; read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-certificates-of-authorisation-2026-09-08", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms NPCI as the authorised operator of UPI, IMPS, AEPS, RuPay affiliation, NACH and NETC on their own separate dates, so a code list belonging to one of those is not a UPI list." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "in-upi:rule.money-back-within-ten-working-days", "id": "rule.money-back-within-ten-working-days", "rail": "in-upi", "class": "Rule", "name": "The money goes back within ten working days of the customer reporting", "statement": "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.", "rests_on": "rule", "facet": "liability", "parameters": { "time_window": { "count": 10, "unit": "business_day", "from": "receipt", "text": "ten working days from the customer notifying the bank" } }, "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-customer-liability-circular-2017", "section": "paragraph 9", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.remitter-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "in-upi:exc.unauthorised-transaction-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RBI/2017-18/15, paragraph 9, read 2026-09-20. The window is typed with receipt as its anchor because that is the nearest value the schema offers for the bank's receipt of the customer's report; the text says what the clock really runs from.", "confidence": "high" }, "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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI/2017-18/15, DBR.No.Leg.BC.78/09.07.005/2017-18, dated 6 July 2017; page and Annex read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-customer-liability-circular-2017", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the ten working day shadow reversal, value dated to the transaction date, and the bank's discretion to waive customer liability." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.unauthorised-transaction-claim", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.no-upi-app-is-authorised-by-the-reserve-bank", "id": "rule.no-upi-app-is-authorised-by-the-reserve-bank", "rail": "in-upi", "class": "Rule", "name": "The Reserve Bank authorises the operator of UPI, not the apps people pay with", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-certificates-of-authorisation-2026-09-08", "section": "the register as a whole; Retail Payments Organisation, Bharat Bill Payment Operating Units, Prepaid Payment Instrument issuers and Payment Aggregators", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-odr-circular-2020", "section": "Annex 5.2", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.third-party-app-provider", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The RBI certificates of authorisation dated 8 September 2026, read entry by entry for the names, together with RBI/2020-21/21 Annex 5.2, read 2026-09-20. The claim that no app is authorised for UPI rests on reading the register and finding nothing, which is weaker evidence than a statement would be.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-08", "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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI certificates of authorisation dated 8 September 2026 and the RBI payment systems overview pages; read 2026-09-20", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "in-upi:rule.npci-holds-the-upi-authorisation", "id": "rule.npci-holds-the-upi-authorisation", "rail": "in-upi", "class": "Rule", "name": "NPCI holds the authorisation for UPI, dated 24 August 2016", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-certificates-of-authorisation-2026-09-08", "section": "Retail Payments Organisation, entry 1 and its footnote", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-payment-systems-overview", "section": "paragraph naming the systems NPCI operates", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.npci", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The RBI certificates of authorisation dated 8 September 2026 and the RBI payment systems overview page, read 2026-09-20.", "confidence": "high" }, "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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI certificates of authorisation dated 8 September 2026 and the RBI payment systems overview pages; read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-certificates-of-authorisation-2026-09-08", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms NPCI's Retail Payments Organisation entry listing Unified Payments Interface authorised 24.08.2016 among its other systems, and the footnote transferring international activity approvals to NIPL effective 10 August 2020." }, { "source": "in-upi:src.rbi-payment-systems-overview", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that NPCI operates UPI among the payment systems the Reserve Bank names it as running as a Retail Payments Organisation." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "in-upi:rule.ombudsman-costs-nothing-and-what-it-can-award", "id": "rule.ombudsman-costs-nothing-and-what-it-can-award", "rail": "in-upi", "class": "Rule", "name": "The ombudsman costs the customer nothing and can award compensation", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-integrated-ombudsman-faq-2026", "section": "questions 21, 22 and 23", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.rbi-ombudsman", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "in-upi:exc.ombudsman-complaint", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The Reserve Bank's 2026 questions and answers updated 1 July 2026, questions 21, 22 and 23, read 2026-09-20. A lakh is one hundred thousand rupees, so the two figures are 3,000,000 and 300,000 rupees.", "confidence": "medium" }, "currency": { "effective_since": "2026-07-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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI notification CEPD.PRD.No.S873/13.01.001/2021-22 of 12 November 2021 and the RB-IOS 2026 questions and answers updated 1 July 2026; read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-integrated-ombudsman-faq-2026", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms no fee to file or resolve a complaint, no ceiling on the amount in dispute, and compensation up to 30 lakh rupees for consequential loss and up to 3 lakh rupees for time, expense, harassment or mental anguish." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.ombudsman-complaint", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.ombudsman-how-a-complaint-ends", "id": "rule.ombudsman-how-a-complaint-ends", "rail": "in-upi", "class": "Rule", "name": "How an ombudsman complaint ends", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-integrated-ombudsman-faq-2026", "section": "questions 24 and 26", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.rbi-ombudsman", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "in-upi:exc.ombudsman-complaint", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The Reserve Bank's 2026 questions and answers updated 1 July 2026, questions 24 and 26, read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "2026-07-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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI notification CEPD.PRD.No.S873/13.01.001/2021-22 of 12 November 2021 and the RB-IOS 2026 questions and answers updated 1 July 2026; read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-integrated-ombudsman-faq-2026", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the maintainability check, the reply from the institution, and the three outcomes of settlement, award or rejection." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.ombudsman-complaint", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.ombudsman-scheme-2021-covers-system-participants", "id": "rule.ombudsman-scheme-2021-covers-system-participants", "rail": "in-upi", "class": "Rule", "name": "The 2021 ombudsman scheme covered system participants as well as banks", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-integrated-ombudsman-notification-2021", "section": "paragraphs 1, 2 and 5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.rbi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "in-upi:exc.ombudsman-complaint", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RBI notification CEPD.PRD.No.S873/13.01.001/2021-22 of 12 November 2021, paragraphs 1, 2 and 5, read 2026-09-20. The scheme text itself, where system participant is defined, is a PDF on rbidocs.rbi.org.in, which returned nothing, so the definition was not read.", "confidence": "high" }, "currency": { "effective_since": "2021-11-12", "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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI notification CEPD.PRD.No.S873/13.01.001/2021-22 of 12 November 2021 and the RB-IOS 2026 questions and answers updated 1 July 2026; read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-integrated-ombudsman-notification-2021", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the merger of the three prior schemes into RB-IOS 2021, its 12 November 2021 commencement, and its coverage of commercial banks, regional rural banks, the larger urban co-operative banks, the larger non-banking financial companies and all system participants as the scheme defines them." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.ombudsman-complaint", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.ombudsman-scheme-2026-replaced-2021", "id": "rule.ombudsman-scheme-2026-replaced-2021", "rail": "in-upi", "class": "Rule", "name": "A newer ombudsman scheme replaced the 2021 one on 1 July 2026", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-integrated-ombudsman-faq-2026", "section": "questions 1, 3 and 13", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-integrated-ombudsman-notification-2021", "section": "paragraph 2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-tat-circular-2019", "section": "paragraph 6", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-odr-circular-2020", "section": "paragraph 4", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.rbi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "in-upi:exc.ombudsman-complaint", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The Reserve Bank's 2026 questions and answers updated 1 July 2026, questions 1, 3 and 13, read alongside the 2021 notification and the two circulars, 2026-09-20. Whether a UPI customer's route to an ombudsman changed with the category list is [Unverified]: the 2026 scheme text is a PDF on rbidocs.rbi.org.in, which returned nothing, and the questions and answers say the detailed coverage is in the scheme.", "confidence": "medium" }, "currency": { "effective_since": "2026-07-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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI notification CEPD.PRD.No.S873/13.01.001/2021-22 of 12 November 2021 and the RB-IOS 2026 questions and answers updated 1 July 2026; read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-integrated-ombudsman-faq-2026", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the 1 July 2026 commencement of RB-IOS 2026, its replacement of the 2021 scheme, the transitional rule for pre-existing complaints and appeals, and the 2026 covered entity list of banks, certain NBFCs, non-bank prepaid instrument issuers and credit information companies, which does not repeat the 2021 notification's system participant category." }, { "source": "in-upi:src.rbi-integrated-ombudsman-notification-2021", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the 2021 scheme's own coverage list of commercial banks, regional rural banks, urban co-operative banks, non-banking financial companies and all system participants, against which the 2026 list is compared." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.ombudsman-complaint", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.ombudsman-when-a-complaint-may-be-filed", "id": "rule.ombudsman-when-a-complaint-may-be-filed", "rail": "in-upi", "class": "Rule", "name": "When a customer may go to the ombudsman, and by when", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-integrated-ombudsman-faq-2026", "section": "questions 16 and 17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.customer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.rbi-ombudsman", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "in-upi:exc.ombudsman-complaint", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The Reserve Bank's 2026 questions and answers updated 1 July 2026, questions 16 and 17, read 2026-09-20. The record rests on the Reserve Bank's own explanation rather than the scheme text, which is on a host that returned nothing, so it stays at medium.", "confidence": "medium" }, "currency": { "effective_since": "2026-07-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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI notification CEPD.PRD.No.S873/13.01.001/2021-22 of 12 November 2021 and the RB-IOS 2026 questions and answers updated 1 July 2026; read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-integrated-ombudsman-faq-2026", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the 30 day or RBI/NPCI/card network specified wait, the 90 day window to reach the ombudsman, the Limitation Act 1963 condition, and that NPCI's own timelines can lengthen the first wait." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.ombudsman-complaint", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.operator-must-run-dispute-resolution", "id": "rule.operator-must-run-dispute-resolution", "rail": "in-upi", "class": "Rule", "name": "Every authorised operator must run an online dispute resolution system for failed transactions", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-odr-circular-2020", "section": "paragraph 3; Annex 1.1, 3.1 and 3.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.npci", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.payment-system-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "in-upi:exc.odr-grievance", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RBI/2020-21/21, paragraph 3 and Annex 1.1, 3.1 and 3.2, read 2026-09-20.", "confidence": "high" }, "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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI/2020-21/21, DPSS.CO.PD No.116/02.12.004/2020-21, dated 6 August 2020; page read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-odr-circular-2020", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the operator's duty to implement an ODR system by 1 January 2021 and give participants access to it, and that both operator and participant must serve customers regardless of whether a transaction stayed on-us or crossed off-us." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.odr-grievance", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.payments-regulatory-board-governs", "id": "rule.payments-regulatory-board-governs", "rail": "in-upi", "class": "Rule", "name": "The board that governs payment systems, and the Reserve Bank's own disagreement about it", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-payment-systems-overview", "section": "Payments Regulatory Board paragraph and member table", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-payment-and-settlement-systems-page", "section": "Board for Regulation and Supervision paragraph", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.rbi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.payments-regulatory-board", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The Reserve Bank's two payment systems overview pages, read 2026-09-20. Which board governs today is a disagreement between two pages of the same publisher; that the newer page governs is an [Inference]. The Payments Regulatory Board Regulations, 2025 are a PDF on rbidocs.rbi.org.in, which returned nothing, so they were not read.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the pages read do not date the change from one board to the other", "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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI certificates of authorisation dated 8 September 2026 and the RBI payment systems overview pages; read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-payment-systems-overview", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that the Reserve Bank is the designated authority for regulation and supervision of payment systems and exercises its section 3(1) and 3(2) powers through the Payments Regulatory Board." }, { "source": "in-upi:src.rbi-payment-and-settlement-systems-page", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that this older overview page still calls the Board for Regulation and Supervision of Payment and Settlement Systems the highest policy making body on payment systems." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "in-upi:rule.recall-not-held", "id": "rule.recall-not-held", "rail": "in-upi", "class": "Rule", "name": "Whether a sent UPI payment can be recalled is not held", "statement": "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.", "rests_on": "guidance", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-certificates-of-authorisation-2026-09-08", "section": "Retail Payments Organisation, entry 1, Unified Payments Interface, 24.08.2016", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-payment-systems-overview", "section": "paragraph naming the systems NPCI operates", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.npci", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "That NPCI operates UPI and writes its rules rests on the RBI certificates of authorisation dated 8 September 2026 and the RBI payment systems overview page, read 2026-09-20. That the documents are not readable rests on a plain request to www.npci.org.in on 2026-09-20, which returned HTTP 403, as did a request for its robots.txt. The record asserts nothing about what the rules say.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-20", "effective_to": null, "effective_note": "Drafted 2026-09-20. The record 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": "RBI certificates of authorisation dated 8 September 2026 and the RBI payment systems overview pages; read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-certificates-of-authorisation-2026-09-08", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms NPCI as the authorised operator of UPI; the record asserts nothing about a UPI recall right." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "in-upi:rule.refund-not-held", "id": "rule.refund-not-held", "rail": "in-upi", "class": "Rule", "name": "How a UPI refund is made is not held", "statement": "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.", "rests_on": "guidance", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-certificates-of-authorisation-2026-09-08", "section": "Retail Payments Organisation, entry 1, Unified Payments Interface, 24.08.2016", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-payment-systems-overview", "section": "paragraph naming the systems NPCI operates", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.npci", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "That NPCI operates UPI and writes its rules rests on the RBI certificates of authorisation dated 8 September 2026 and the RBI payment systems overview page, read 2026-09-20. That the documents are not readable rests on a plain request to www.npci.org.in on 2026-09-20, which returned HTTP 403, as did a request for its robots.txt. The record asserts nothing about what the rules say.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-20", "effective_to": null, "effective_note": "Drafted 2026-09-20. The record 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": "RBI certificates of authorisation dated 8 September 2026 and the RBI payment systems overview pages; read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-certificates-of-authorisation-2026-09-08", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms NPCI as the authorised operator of UPI; the record asserts nothing about UPI refund mechanics." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "in-upi:rule.risk-based-checks-above-the-minimum", "id": "rule.risk-based-checks-above-the-minimum", "rail": "in-upi", "class": "Rule", "name": "An issuer may add checks above the minimum where the risk warrants it", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-authentication-directions-2025", "section": "paragraph 8", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.remitter-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RBI/2025-26/79, paragraph 8, read 2026-09-20. The closing sentence is Orca's reading across the documents held for this rail, which is why the record stays at medium.", "confidence": "medium" }, "currency": { "effective_since": "2026-04-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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI/2025-26/79, CO.DPSS.POLC.No. S 668/02-14-015/2025-2026, dated 25 September 2025; page and both Annexures read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-authentication-directions-2025", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that an issuer may evaluate transactions against behavioural and contextual parameters and apply additional checks beyond the two factor minimum based on perceived risk." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "in-upi:rule.settlement-not-held", "id": "rule.settlement-not-held", "rail": "in-upi", "class": "Rule", "name": "How and when UPI positions settle is not held", "statement": "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.", "rests_on": "guidance", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-certificates-of-authorisation-2026-09-08", "section": "Retail Payments Organisation, entry 1, Unified Payments Interface, 24.08.2016", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-payment-systems-overview", "section": "paragraph naming the systems NPCI operates", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.npci", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "That NPCI operates UPI and writes its rules rests on the RBI certificates of authorisation dated 8 September 2026 and the RBI payment systems overview page, read 2026-09-20. That the documents are not readable rests on a plain request to www.npci.org.in on 2026-09-20, which returned HTTP 403, as did a request for its robots.txt. The record asserts nothing about what the rules say.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-20", "effective_to": null, "effective_note": "Drafted 2026-09-20. The record 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": "RBI certificates of authorisation dated 8 September 2026 and the RBI payment systems overview pages; read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-certificates-of-authorisation-2026-09-08", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms NPCI as the authorised operator of UPI; the record asserts nothing about UPI's settlement mechanics." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "in-upi:rule.tpap-in-app-dispute-lodging", "id": "rule.tpap-in-app-dispute-lodging", "rail": "in-upi", "class": "Rule", "name": "On UPI, a third party app must let the customer raise the dispute inside the app they paid in", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-odr-circular-2020", "section": "Annex 5.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.third-party-app-provider", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "in-upi:exc.odr-grievance", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "in-upi:rule.dispute-lodging-channels-and-tracking", "note": "The general duty this one is the UPI specific case of. That record is Annex 5.1, 5.3 and 5.4, binding the operator and the customer's own institution; this one is Annex 5.2, binding a third party application provider.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RBI/2020-21/21, Annex 5.2, read 2026-09-20, which names UPI and third party app providers in terms.", "confidence": "high" }, "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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI/2020-21/21, DPSS.CO.PD No.116/02.12.004/2020-21, dated 6 August 2020; page read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-odr-circular-2020", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that a third party app provider on a system such as UPI must provide a facility to lodge disputes in the same app, integrated with the ODR system." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.odr-grievance", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.dispute-lodging-channels-and-tracking", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.transaction-day-and-reversal-day", "id": "rule.transaction-day-and-reversal-day", "rail": "in-upi", "class": "Rule", "name": "How the two days in the deadline are counted", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-tat-circular-2019", "section": "Annex, general instructions 4 and 5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.remitter-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "in-upi:exc.auto-reversal", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RBI/2019-20/67, Annex general instructions 4 and 5, read 2026-09-20. No time window is typed: the schema's window anchors are a settlement date, a receipt, a notice of refusal, a determination, a discovery and a statement, and none of them is the calendar date of the transaction.", "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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI/2019-20/67, DPSS.CO.PD No.629/02.01.014/2019-20, dated 20 September 2019, in effect from 15 October 2019; page read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-tat-circular-2019", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that T is the calendar date of the transaction and R is the day the reversal concludes and funds reach the issuer or originator, to be credited the same day." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.auto-reversal", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.transaction-limits-not-held", "id": "rule.transaction-limits-not-held", "rail": "in-upi", "class": "Rule", "name": "UPI's per transaction and per day limits are not held", "statement": "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.", "rests_on": "guidance", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-certificates-of-authorisation-2026-09-08", "section": "Retail Payments Organisation, entry 1, Unified Payments Interface, 24.08.2016", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-payment-systems-overview", "section": "paragraph naming the systems NPCI operates", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.npci", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "That NPCI operates UPI and writes its rules rests on the RBI certificates of authorisation dated 8 September 2026 and the RBI payment systems overview page, read 2026-09-20. That the documents are not readable rests on a plain request to www.npci.org.in on 2026-09-20, which returned HTTP 403, as did a request for its robots.txt. The record asserts nothing about what the rules say.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-20", "effective_to": null, "effective_note": "Drafted 2026-09-20. The record 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": "RBI certificates of authorisation dated 8 September 2026 and the RBI payment systems overview pages; read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-certificates-of-authorisation-2026-09-08", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms NPCI as the authorised operator of UPI; the record asserts nothing about a UPI value limit beyond the e-mandate authentication threshold it already holds." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "in-upi:rule.two-factors-of-authentication", "id": "rule.two-factors-of-authentication", "rail": "in-upi", "class": "Rule", "name": "A digital payment is authenticated with at least two distinct factors", "statement": "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.", "rests_on": "rule", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-authentication-directions-2025", "section": "paragraphs 5, 6(a), 6(b) and 6(c)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.remitter-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.payment-system-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "in-upi:txn.funds-transfer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "in-upi:txn.merchant-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "in-upi:txn.123pay", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "in-upi:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RBI/2025-26/79, paragraphs 4, 5 and 6, read 2026-09-20. The directions are not UPI specific; paragraph 4 applies them to all domestic digital payment transactions by every payment system provider and participant, which takes in every kind of UPI payment this rail holds.", "confidence": "high" }, "currency": { "effective_since": "2026-04-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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI/2025-26/79, CO.DPSS.POLC.No. S 668/02-14-015/2025-2026, dated 25 September 2025; page and both Annexures read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-authentication-directions-2025", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the two factor minimum, the definition and examples of a factor, the dynamic factor requirement outside card present payments, the robustness principle, and the issuer's discretion to offer a choice of factors." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "in-upi:rule.upi-and-imps-are-separate-rows", "id": "rule.upi-and-imps-are-separate-rows", "rail": "in-upi", "class": "Rule", "name": "UPI and the Immediate Payment Service are separate systems with separate deadlines", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-tat-circular-2019", "section": "Annex, rows 3(a), 4(a) and 4(b)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-certificates-of-authorisation-2026-09-08", "section": "Retail Payments Organisation, entry 1: Immediate Payment Service 12.10.2010 and Unified Payments Interface 24.08.2016", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "RBI/2019-20/67 Annex rows 3 and 4, and the RBI certificates of authorisation dated 8 September 2026, read 2026-09-20. The Reserve Bank authorised the two as separate payment systems on separate dates. Whether UPI runs on the Immediate Payment Service underneath is [Unverified]: no document read says so either way.", "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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI/2019-20/67, DPSS.CO.PD No.629/02.01.014/2019-20, dated 20 September 2019, in effect from 15 October 2019; page read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-tat-circular-2019", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that the Immediate Payment Service and UPI have separate rows in the Annex table, with different deadlines." }, { "source": "in-upi:src.rbi-certificates-of-authorisation-2026-09-08", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the Immediate Payment Service authorised on 12 October 2010 and the Unified Payments Interface authorised on 24 August 2016 as separate entries for NPCI." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "in-upi:rule.upi-autopay-every-mandate-event-is-notified", "id": "rule.upi-autopay-every-mandate-event-is-notified", "rail": "in-upi", "class": "Rule", "name": "UPI AutoPay: the customer hears about every change to a mandate, twice", "statement": "Each thing that happens to an AutoPay mandate reaches the customer through two channels: an SMS from their bank and a notification from their UPI app. That covers the mandate's own life (setting it up, changing it, pausing it, lifting the pause, revoking it) as well as each debit (the notice before it, the debit itself and the notice after it). Expiry at the end of the validity period is not on the list for AutoPay.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "in-upi:src.npci-upi-consolidated-circular-2026", "section": "section 14.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.remitter-bank", "note": "the SMS", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.third-party-app-provider", "note": "the in-app notification; section 14.3 binds the Payer PSP and the UPI Application Provider, a PSP or a TPAP", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "in-upi:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPCI/UPI/CC/01 version 1.0 of 18 September 2026, section 14.3, read 2026-09-24. The absence of expiry is read from the list in section 14.3 and contrasted with section 16.11, which names expiry among the notified operations for UPI Reserve Pay; whether AutoPay apps notify an expiry in practice is not held.", "confidence": "high" }, "currency": { "effective_since": "2026-09-18", "effective_to": null, "effective_note": "Drafted 2026-09-24 from NPCI's UPI Consolidated Circular version 1.0, read from a copy Dave saved from npci.org.in on 2026-09-23 because that host refuses automated requests. The date is the circular's issue date. The circular consolidates Operating Circulars issued up to 31 July 2026 and says it changes none of their effective dates; those circulars were not read, so the rule may have applied earlier.", "source_edition": "NPCI/UPI/CC/01, UPI Consolidated Circular version 1.0, issued 18 September 2026; copy saved 2026-09-23", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.npci-upi-consolidated-circular-2026", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms section 14.3 requiring the remitter bank to send an SMS and the payer PSP or UPI application provider to send an app notification for every AutoPay transaction, naming registration, pre-debit notification, execution, post-debit notification, modification, pause, unpause and revoke. Confirms expiry is absent from that list and, by contrast, is named among the events UPI Reserve Pay must notify under section 16.11." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:state.upi-autopay-paused", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:state.upi-autopay-revoked", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.upi-autopay-modification", "id": "rule.upi-autopay-modification", "rail": "in-upi", "class": "Rule", "name": "UPI AutoPay: changing a live mandate's amount or payee", "statement": "A registered AutoPay mandate can be changed without being cancelled and set up again, and the change leaves it live. The amount is changed on the merchant's side: the payee PSP must see that its merchants give the customer a way to do it. The end date is changed through the customer's bank, under the validity rule. The merchant's own UPI ID on a mandate is different: a merchant may move to a new UPI ID while keeping its merchant identifier code and every other mandate term, but the payee PSP may let the payee UPI ID on an active mandate change only when a regulator directs it or the payee PSP stops offering the service.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "in-upi:src.npci-upi-consolidated-circular-2026", "section": "sections 14.16, 14.17, 14.24.6 and 14.24.7", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.merchant", "note": "sections 14.17 and 14.24.7 put the duty on the payee PSP, acting through or on its merchants; Orca holds no separate Role for a payee PSP", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.remitter-bank", "note": "section 14.16, changing the validity period", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "in-upi:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPCI/UPI/CC/01 version 1.0 of 18 September 2026, sections 14.16, 14.17, 14.24.6 and 14.24.7, read 2026-09-24. That a modified mandate stays live rather than passing through a state of its own is [Inference]: the circular names modification as an operation that must be notified (section 14.3) and defines no pending or modified status. Whether an amount change needs the customer's additional factor of authentication is not stated in the circular; the Reserve Bank's E-mandate Framework 2026 requires it for a modification (in-upi:rule.e-mandate-registration-and-withdrawal).", "confidence": "medium" }, "currency": { "effective_since": "2026-09-18", "effective_to": null, "effective_note": "Drafted 2026-09-24 from NPCI's UPI Consolidated Circular version 1.0, read from a copy Dave saved from npci.org.in on 2026-09-23 because that host refuses automated requests. The date is the circular's issue date. The circular consolidates Operating Circulars issued up to 31 July 2026 and says it changes none of their effective dates; those circulars were not read, so the rule may have applied earlier.", "source_edition": "NPCI/UPI/CC/01, UPI Consolidated Circular version 1.0, issued 18 September 2026; copy saved 2026-09-23", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "in-upi:state.e-mandate-registered", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.upi-autopay-pause-and-unpause", "id": "rule.upi-autopay-pause-and-unpause", "rail": "in-upi", "class": "Rule", "name": "UPI AutoPay: pausing a mandate and lifting the pause", "statement": "On UPI a customer can hold back debits under an AutoPay mandate without ending it: NPCI treats opting out of a particular debit and pausing the mandate as one facility, and lifting it again is called unpause (resume in the UPI HELP section). The customer's UPI app must offer the pause, except on mandates in the Loan Payments and EMI Collection categories, where that duty on the app does not apply. The customer's own bank must offer it with no such exception written. NPCI's UPI HELP assistant may also start a pause or a resume, and must then hand the customer to the ordinary AutoPay confirmation screen. On the other side, the payee PSP must make sure every merchant that takes AutoPay payments can cope with a paused mandate. The circular sets no maximum length for a pause and does not say whether one pause may cover several debits.", "rests_on": "rule", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "in-upi:src.npci-upi-consolidated-circular-2026", "section": "sections 14.18, 14.19, 14.20 and 33.4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.remitter-bank", "note": "section 14.18; the circular's Remitter Bank, which it says is the issuer in UPI", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.third-party-app-provider", "note": "section 14.19 binds the Payer PSP and the UPI Application Provider, which the circular defines as a PSP or a TPAP offering a UPI app; Orca holds no separate Role for a payer PSP", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.merchant", "note": "section 14.20 puts the duty on the payee PSP to ensure its merchants support pause; Orca holds no separate Role for a payee PSP", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "in-upi:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPCI/UPI/CC/01 version 1.0 of 18 September 2026, sections 14.18 to 14.20 and 33.4, read 2026-09-24. That the Loan Payments and EMI Collection exception limits only the app's duty, and does not forbid a pause in those categories, is [Inference]: section 14.19 frames it as an exception to what the app must provide, and section 14.18 gives the bank's duty with no exception. What a pause does to the pre-debit notice and to the debit retries is not stated.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-18", "effective_to": null, "effective_note": "Drafted 2026-09-24 from NPCI's UPI Consolidated Circular version 1.0, read from a copy Dave saved from npci.org.in on 2026-09-23 because that host refuses automated requests. The date is the circular's issue date. The circular consolidates Operating Circulars issued up to 31 July 2026 and says it changes none of their effective dates; those circulars were not read, so the rule may have applied earlier.", "source_edition": "NPCI/UPI/CC/01, UPI Consolidated Circular version 1.0, issued 18 September 2026; copy saved 2026-09-23", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.npci-upi-consolidated-circular-2026", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms section 14.18 requiring the customer's bank to offer a facility to opt out of a particular transaction, which the same section labels pause, or to revoke the mandate, and section 14.19 requiring the customer's UPI app to offer pause or revoke except on Loan Payments and EMI Collection mandates. Confirms section 33.4 lets UPI HELP start a pause or a resume and then hand the customer to the usual AutoPay confirmation screen, and section 14.20 puts a duty on the payee PSP to ensure merchants taking AutoPay payments can handle a paused mandate. Confirms unpause appears as a named event in the section 14.3 notification list. Does not state a maximum length for a pause or say whether one pause can cover more than one debit." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:state.upi-autopay-paused", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.upi-autopay-revocation", "id": "rule.upi-autopay-revocation", "rail": "in-upi", "class": "Rule", "name": "UPI AutoPay: revoking a mandate, from either side", "statement": "An AutoPay mandate can be ended from the merchant's side as well as the customer's. Whatever kind of business the merchant is, its payee PSP must see that the customer can revoke from the merchant's own website or app, and the revocation must travel through the UPI AutoPay channel so the mandate ends everywhere, not merely vanish from the merchant's records. A withdrawal made on the merchant's platform needs no additional factor of authentication under UPI's rules. On the customer's side the bank must offer revocation, the customer's UPI app must offer it except on Loan Payments and EMI Collection mandates, and UPI HELP may start one and then pass the customer to the usual AutoPay confirmation screen. Once any member finds a mandate operation failing because the mandate has been revoked or does not exist, it must delete the mandate from its own systems too.", "rests_on": "rule", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "in-upi:src.npci-upi-consolidated-circular-2026", "section": "sections 14.18, 14.19, 14.21, 14.22, 14.23 and 33.4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.remitter-bank", "note": "sections 14.18 and 14.22", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.third-party-app-provider", "note": "sections 14.19 and 33.4 bind the Payer PSP and the UPI Application Provider, a PSP or a TPAP; Orca holds no separate Role for a payer PSP", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.merchant", "note": "section 14.21 puts the duty on the payee PSP to ensure revocation is offered on the merchant's platform; Orca holds no separate Role for a payee PSP", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "in-upi:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPCI/UPI/CC/01 version 1.0 of 18 September 2026, sections 14.18, 14.19, 14.21 to 14.23 and 33.4, read 2026-09-24. The circular uses revoke for the operation and, in section 14.23 only, withdrawal. Two points are open. First, the Reserve Bank's E-mandate Framework 2026 requires the additional factor to withdraw a mandate (in-upi:rule.e-mandate-registration-and-withdrawal), while section 14.23 waives it on the merchant's platform; section 1.6 of the circular says applicable law prevails in a conflict, and whether the two actually conflict (for example because the merchant platform path is treated as the merchant's cancellation, not the customer's) is not settled here. Second, whether a merchant may revoke on its own initiative, rather than on the customer's request made on its platform, is not stated.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-18", "effective_to": null, "effective_note": "Drafted 2026-09-24 from NPCI's UPI Consolidated Circular version 1.0, read from a copy Dave saved from npci.org.in on 2026-09-23 because that host refuses automated requests. The date is the circular's issue date. The circular consolidates Operating Circulars issued up to 31 July 2026 and says it changes none of their effective dates; those circulars were not read, so the rule may have applied earlier.", "source_edition": "NPCI/UPI/CC/01, UPI Consolidated Circular version 1.0, issued 18 September 2026; copy saved 2026-09-23", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.npci-upi-consolidated-circular-2026", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms section 14.21 requiring the payee PSP to make a revoke facility available on the merchant's own website or app, with the request routed to the UPI AutoPay channel rather than deleted only on the merchant's side, and section 14.23 waiving the additional factor of authentication for a withdrawal made through the merchant platform. Confirms revocation is also required from the customer's bank under section 14.18, from the customer's UPI app except on Loan Payments and EMI Collection mandates under section 14.19, and from UPI HELP under section 33.4, and that section 14.22 requires a member finding an operation fail because a mandate is revoked or missing to delete that mandate from its own systems. Does not settle whether section 14.23's waiver of the additional factor conflicts with the Reserve Bank's e-mandate framework, which requires an additional factor for any withdrawal; that question is left open." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:mandate.upi-recurring", "type": "revoked_via", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:state.upi-autopay-revoked", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.upi-autopay-validity-and-expiry", "id": "rule.upi-autopay-validity-and-expiry", "rail": "in-upi", "class": "Rule", "name": "UPI AutoPay: a mandate lasts at most 30 years and lapses at its end date", "statement": "No AutoPay mandate is open-ended. Each one is registered with a validity period, and the payee PSP must keep that period to 30 years or less. When the customer sets the mandate up, the merchant's flow must let them change the end date, and afterwards the customer's bank must let them change the validity period whenever they like, having told them at registration that they can. When the period runs out, NPCI's glossary treats the mandate as expired and no longer valid, with no act by either side needed to end it.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "in-upi:src.npci-upi-consolidated-circular-2026", "section": "sections 14.5 and 14.16; Annexure A, Mandate Validity Period", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.remitter-bank", "note": "section 14.16", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.merchant", "note": "section 14.5 puts the 30-year ceiling and the end-date option on the payee PSP, acting through the merchant; Orca holds no separate Role for a payee PSP", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "in-upi:txn.recurring", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPCI/UPI/CC/01 version 1.0 of 18 September 2026, sections 14.5 and 14.16 and the Annexure A definition of Mandate Validity Period, read 2026-09-24. The 30-year ceiling cannot be carried in parameters: time_window has no year unit and no registration anchor. Whether the customer is told when a mandate expires is not stated for AutoPay: section 14.3 lists the operations that must be notified and expiry is not among them, while section 16.11 lists expiry for UPI Reserve Pay.", "confidence": "high" }, "currency": { "effective_since": "2026-09-18", "effective_to": null, "effective_note": "Drafted 2026-09-24 from NPCI's UPI Consolidated Circular version 1.0, read from a copy Dave saved from npci.org.in on 2026-09-23 because that host refuses automated requests. The date is the circular's issue date. The circular consolidates Operating Circulars issued up to 31 July 2026 and says it changes none of their effective dates; those circulars were not read, so the rule may have applied earlier.", "source_edition": "NPCI/UPI/CC/01, UPI Consolidated Circular version 1.0, issued 18 September 2026; copy saved 2026-09-23", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.npci-upi-consolidated-circular-2026", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms section 14.5 requiring the payee PSP to keep every mandate's validity period to 30 years or less and to let the customer edit the end date at registration, section 14.16 requiring the customer's bank to let the customer change the validity period at any later time after telling them of that facility at registration, and the Annexure A glossary's definition of Mandate Validity Period, which treats the mandate as deemed expired and invalid once the period ends with no act required by either side." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:state.e-mandate-registered", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:state.upi-autopay-expired", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.what-counts-as-a-failed-transaction", "id": "rule.what-counts-as-a-failed-transaction", "rail": "in-upi", "class": "Rule", "name": "What counts as a failed transaction", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-tat-circular-2019", "section": "Annex, general instruction 2; paragraph 2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "in-upi:exc.auto-reversal", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RBI/2019-20/67, Annex general instruction 2 and paragraph 2, read 2026-09-20. The closing sentence is an [Inference] from what the definition covers.", "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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI/2019-20/67, DPSS.CO.PD No.629/02.01.014/2019-20, dated 20 September 2019, in effect from 15 October 2019; page read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-tat-circular-2019", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the definition of a failed transaction as one not attributable to the customer, including missing information and delayed reversal initiation." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.auto-reversal", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:rule.zero-liability-for-the-customer", "id": "rule.zero-liability-for-the-customer", "rail": "in-upi", "class": "Rule", "name": "When the customer owes nothing on a transaction they did not authorise", "statement": "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.", "rests_on": "rule", "facet": "liability", "parameters": { "liability_holder": { "role": "in-upi:role.remitter-bank", "condition": "the bank contributed to the loss, or the fault lay elsewhere in the system and the customer reported within three working days of the bank's communication", "text": "the bank bears the whole loss" } }, "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-customer-liability-circular-2017", "section": "paragraph 6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "in-upi:role.remitter-bank", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "in-upi:exc.unauthorised-transaction-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RBI/2017-18/15, paragraph 6, read 2026-09-20. That this reaches a UPI payment is an [Inference]: the circular covers remote payment transactions as a category, including mobile banking, and does not name UPI.", "confidence": "high" }, "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 nothing here rests on UPI's own scheme rules.", "source_edition": "RBI/2017-18/15, DBR.No.Leg.BC.78/09.07.005/2017-18, dated 6 July 2017; page and Annex read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-customer-liability-circular-2017", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms zero liability where the bank's own fraud, negligence or deficiency contributed, and where the fault lay elsewhere in the system and the customer reported within three working days of the bank's communication." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.unauthorised-transaction-claim", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:src.npci-upi-consolidated-circular-2026", "id": "src.npci-upi-consolidated-circular-2026", "rail": "in-upi", "class": "RuleSource", "name": "NPCI UPI Consolidated Circular, version 1.0 (2026)", "summary": "The operator's own rulebook-level circular for UPI, issued by NPCI as the authorised operator under the PSS Act 2007. It folds the UPI Operating Circulars issued up to 31 July 2026 into one document, withdraws the ones listed in its Annexure G, and leaves the Procedural Guidelines, the Operating and Settlement Guidelines, the technical specifications and the error and response code document in force beside it. Part III section 14 covers UPI AutoPay: registration, notice before and after each debit, changing a mandate, pausing and unpausing it, revoking it from the bank, the app or the merchant's side, and porting it between apps; Annexure A defines when a mandate expires. It says that where it conflicts with applicable law, the law governs.", "publisher": "National Payments Corporation of India", "url": "https://www.npci.org.in/uploads/UPI_Consolidated_Circular_f9c023a0ef.pdf", "source_class": "authoritative_primary", "kind": "operating circular", "edition": "NPCI/UPI/CC/01, UPI Consolidated Circular version 1.0, issued 18 September 2026 (54 pages)", "access": "open", "consulted_on": "2026-09-24", "relations": [], "basis": { "sources": "The document itself, read in full on 2026-09-24 from the copy Dave saved on 2026-09-23 into the orca-sources folder outside the repository (NPCI's host refuses automated requests, docs/rails/in-upi.md Access note 2). Sections 1, 14, 33 and 35 and Annexures A and G were read closely for this record. Every page carries NPCI's copyright notice; Orca cites it by section and does not reproduce it.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-24 for the in-upi rail. access is open because NPCI publishes the circular free on its public site; that site answers every automated request with HTTP 403, so an agent cannot fetch it and a watch cannot check it, and the copy read was saved by a person with Dave's approval (docs/chief-of-staff.md, UPI 1). Section 1.4 footnote: the circular changes no fee, effective date, timeline or technical requirement of the Operating Circulars it consolidates, none of which was read. Section 35.1: NPCI may amend it from time to time, so a later version number supersedes this edition.", "source_edition": "NPCI/UPI/CC/01, UPI Consolidated Circular version 1.0, issued 18 September 2026; copy saved 2026-09-23", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "in-upi:rule.upi-autopay-every-mandate-event-is-notified", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.upi-autopay-modification", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.upi-autopay-pause-and-unpause", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.upi-autopay-revocation", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.upi-autopay-validity-and-expiry", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:state.e-mandate-registered", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:state.upi-autopay-expired", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:state.upi-autopay-paused", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:state.upi-autopay-revoked", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "in-upi:src.rbi-authentication-directions-2025", "id": "src.rbi-authentication-directions-2025", "rail": "in-upi", "class": "RuleSource", "name": "Reserve Bank of India (Authentication mechanisms for digital payment transactions) Directions, 2025", "summary": "The Reserve Bank's principles for authenticating a digital payment: at least two distinct factors, at least one of them dynamic outside a card present transaction, and factors that do not fall together. It puts the cost of a non compliant authentication on the issuer and lists the exempted use cases, one of which is a UPI tap and pay payment at a near field communication terminal.", "publisher": "Reserve Bank of India", "url": "https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=12898&Mode=0", "source_class": "authoritative_primary", "kind": "directions", "edition": "RBI/2025-26/79, CO.DPSS.POLC.No. S 668/02-14-015/2025-2026, dated 25 September 2025, compliance by 1 April 2026; the live page, with both Annexures, as read 2026-09-20", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, fetched and read on 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for the in-upi rail. A RuleSource describes one edition of one document; its status stays draft and a watch dates it through consulted_on. The Reserve Bank's terms of use bar caching and linking to its pages without prior permission, and a request for that permission is on Orca's backlog; the record carries the public address because every Orca record cites its source by address.", "source_edition": "RBI/2025-26/79, CO.DPSS.POLC.No. S 668/02-14-015/2025-2026, dated 25 September 2025, compliance by 1 April 2026; the live page, with both Annexures, as read 2026-09-20", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.unauthorised-transaction-claim", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:role.payment-system-participant", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:role.remitter-bank", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.authentication-exemptions-include-upi-tap-and-pay", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.authentication-must-be-open-to-all-applications", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.issuer-pays-in-full-for-bad-authentication", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.risk-based-checks-above-the-minimum", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.two-factors-of-authentication", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:txn.merchant-payment", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:txn.recurring", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "in-upi:src.rbi-certificates-of-authorisation-2026-09-08", "id": "src.rbi-certificates-of-authorisation-2026-09-08", "rail": "in-upi", "class": "RuleSource", "name": "RBI list of certificates of authorisation under the Payment and Settlement Systems Act, 2007", "summary": "The Reserve Bank's published register of every entity it has authorised to set up and operate a payment system in India, grouped by kind of operator, each with the system authorised and the date of authorisation. It is the document that says who holds UPI and, by its silence, who does not. The Reserve Bank republishes this page with a new date, so the date on the page is the edition.", "publisher": "Reserve Bank of India", "url": "https://www.rbi.org.in/Scripts/PublicationsView.aspx?id=12043", "source_class": "authoritative_primary", "kind": "register", "edition": "publication dated 8 September 2026; read 2026-09-20", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, fetched and read on 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for the in-upi rail. A RuleSource describes one edition of one document; its status stays draft and a watch dates it through consulted_on. The Reserve Bank's terms of use bar caching and linking to its pages without prior permission, and a request for that permission is on Orca's backlog; the record carries the public address because every Orca record cites its source by address.", "source_edition": "publication dated 8 September 2026; read 2026-09-20", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "in-upi:rail.in-upi", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:role.npci", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:role.third-party-app-provider", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.authorisation-is-required-to-run-a-payment-system", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.finality-not-held", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.hours-not-held", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.interbank-dispute-rules-not-held", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.messages-not-held", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.no-upi-app-is-authorised-by-the-reserve-bank", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.npci-holds-the-upi-authorisation", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.recall-not-held", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.refund-not-held", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.settlement-not-held", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.transaction-limits-not-held", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.upi-and-imps-are-separate-rows", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "in-upi:src.rbi-customer-liability-circular-2017", "id": "src.rbi-customer-liability-circular-2017", "rail": "in-upi", "class": "RuleSource", "name": "RBI circular on limiting the liability of customers in unauthorised electronic banking transactions (RBI/2017-18/15)", "summary": "The Reserve Bank's framework for who bears the loss when an electronic banking transaction was not authorised by the customer: when the customer owes nothing, when a capped amount is owed, how fast the bank must put the money back, and who must prove what. It covers remote payment transactions as a category and does not name UPI. Addressed to scheduled commercial banks including regional rural banks, small finance banks and payments banks. A separate circular of 14 December 2017 covers co-operative banks and was not read. Whether the framework reaches a UPI payment is an inference from the circular's own category of remote payment transactions, not a statement in it.", "publisher": "Reserve Bank of India", "url": "https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=11040&Mode=0", "source_class": "authoritative_primary", "kind": "circular", "edition": "RBI/2017-18/15, DBR.No.Leg.BC.78/09.07.005/2017-18, dated 6 July 2017; the live page, with its Annex, as read 2026-09-20", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, fetched and read on 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for the in-upi rail. A RuleSource describes one edition of one document; its status stays draft and a watch dates it through consulted_on. The Reserve Bank's terms of use bar caching and linking to its pages without prior permission, and a request for that permission is on Orca's backlog; the record carries the public address because every Orca record cites its source by address.", "source_edition": "RBI/2017-18/15, DBR.No.Leg.BC.78/09.07.005/2017-18, dated 6 July 2017; the live page, with its Annex, as read 2026-09-20", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.unauthorised-transaction-claim", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:role.customer", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:role.remitter-bank", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.alerts-and-channels-for-reporting", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.bank-must-prove-the-customer-is-liable", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.claim-settled-within-ninety-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.e-mandate-disputes-and-liability", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.limited-liability-for-the-customer", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.money-back-within-ten-working-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.zero-liability-for-the-customer", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "in-upi:src.rbi-e-mandate-framework-2026", "id": "src.rbi-e-mandate-framework-2026", "rail": "in-upi", "class": "RuleSource", "name": "RBI Digital Payments E-mandate Framework, 2026", "summary": "The Reserve Bank's consolidated directions for recurring payments taken on a standing authorisation, which state in their applicability paragraph that they cover recurring transactions made using UPI. They set how a mandate is registered and withdrawn, the notice before each charge, the thresholds above which the customer must authenticate again, and that the customer pays nothing for the facility. These directions repealed eight earlier circulars, one of which was the 10 January 2020 circular on processing e-mandates in UPI for recurring transactions. The repealed circulars were not read.", "publisher": "Reserve Bank of India", "url": "https://www.rbi.org.in/Scripts/BS_ViewMasDirections.aspx?id=13374", "source_class": "authoritative_primary", "kind": "directions", "edition": "RBI/DPSS/2026-27/396, RBI/CO.DPSS.POLC.No.S56/02.14.003/2026-27, dated 21 April 2026, effective immediately; the live page as read 2026-09-20", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, fetched and read on 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for the in-upi rail. A RuleSource describes one edition of one document; its status stays draft and a watch dates it through consulted_on. The Reserve Bank's terms of use bar caching and linking to its pages without prior permission, and a request for that permission is on Orca's backlog; the record carries the public address because every Orca record cites its source by address.", "source_edition": "RBI/DPSS/2026-27/396, RBI/CO.DPSS.POLC.No.S56/02.14.003/2026-27, dated 21 April 2026, effective immediately; the live page as read 2026-09-20", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "in-upi:role.merchant", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.e-mandate-authentication-threshold", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.e-mandate-costs-the-customer-nothing", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.e-mandate-disputes-and-liability", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.e-mandate-first-charge", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.e-mandate-framework-covers-upi", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.e-mandate-higher-threshold-for-three-categories", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.e-mandate-notice-after-each-charge", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.e-mandate-notice-before-each-charge", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.e-mandate-registration-and-withdrawal", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:state.e-mandate-registered", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:state.e-mandate-withdrawn", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:txn.recurring", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "in-upi:src.rbi-integrated-ombudsman-faq-2026", "id": "src.rbi-integrated-ombudsman-faq-2026", "rail": "in-upi", "class": "RuleSource", "name": "RBI questions and answers on the Reserve Bank Integrated Ombudsman Scheme, 2026", "summary": "The Reserve Bank's own explanation of the ombudsman scheme now in force: who it covers, when a customer may come to it, the ninety day outer limit for filing, what it may award, and how a complaint is settled, awarded or rejected. It is the Reserve Bank explaining its scheme, not the scheme text. The page carries the 2026 Scheme although the address still says 2021, so the address alone does not say which scheme a reader is looking at. The Scheme text it describes is a PDF on rbidocs.rbi.org.in, which did not answer a request on 2026-09-20.", "publisher": "Reserve Bank of India", "url": "https://www.rbi.org.in/commonperson/english/scripts/FAQs.aspx?Id=3407", "source_class": "public_primary", "kind": "questions_and_answers", "edition": "Reserve Bank Integrated Ombudsman Scheme, 2026 set of questions and answers, updated as on 1 July 2026; read 2026-09-20", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, fetched and read on 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for the in-upi rail. A RuleSource describes one edition of one document; its status stays draft and a watch dates it through consulted_on. The Reserve Bank's terms of use bar caching and linking to its pages without prior permission, and a request for that permission is on Orca's backlog; the record carries the public address because every Orca record cites its source by address.", "source_edition": "Reserve Bank Integrated Ombudsman Scheme, 2026 set of questions and answers, updated as on 1 July 2026; read 2026-09-20", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.ombudsman-complaint", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:role.npci", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:role.rbi-ombudsman", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.interbank-dispute-rules-not-held", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.ombudsman-costs-nothing-and-what-it-can-award", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.ombudsman-how-a-complaint-ends", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.ombudsman-scheme-2026-replaced-2021", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.ombudsman-when-a-complaint-may-be-filed", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "in-upi:src.rbi-integrated-ombudsman-notification-2021", "id": "src.rbi-integrated-ombudsman-notification-2021", "rail": "in-upi", "class": "RuleSource", "name": "RBI notification bringing the Reserve Bank Integrated Ombudsman Scheme, 2021 into force", "summary": "The covering notification that merged the three earlier ombudsman schemes into one, named the categories of regulated entity it covers, including system participants, and set the date it came into force. The Scheme text itself is a PDF on the Reserve Bank's document host, which did not answer a request. Only the covering notification was read. The Scheme text and its amendments sit on rbidocs.rbi.org.in, which accepted a connection and then returned nothing on 2026-09-20, so no clause of the Scheme itself is cited from it.", "publisher": "Reserve Bank of India", "url": "https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=12192&Mode=0", "source_class": "authoritative_primary", "kind": "notification", "edition": "Ref. CEPD.PRD.No.S873/13.01.001/2021-22, dated 12 November 2021, in force from 12 November 2021; the live page as read 2026-09-20", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, fetched and read on 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for the in-upi rail. A RuleSource describes one edition of one document; its status stays draft and a watch dates it through consulted_on. The Reserve Bank's terms of use bar caching and linking to its pages without prior permission, and a request for that permission is on Orca's backlog; the record carries the public address because every Orca record cites its source by address.", "source_edition": "Ref. CEPD.PRD.No.S873/13.01.001/2021-22, dated 12 November 2021, in force from 12 November 2021; the live page as read 2026-09-20", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.ombudsman-complaint", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:role.rbi-ombudsman", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.ombudsman-scheme-2021-covers-system-participants", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.ombudsman-scheme-2026-replaced-2021", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "in-upi:src.rbi-odr-circular-2020", "id": "src.rbi-odr-circular-2020", "rail": "in-upi", "class": "RuleSource", "name": "RBI circular on the Online Dispute Resolution system for digital payments (RBI/2020-21/21)", "summary": "The Reserve Bank's direction that every authorised payment system operator run an online dispute resolution system for failed transactions and open it to its participants. Its Annex sets the minimum requirements, and paragraph 5.2 of that Annex is the only text read for this rail that puts a duty on a UPI third party application provider. Paragraph 4 of the page as read on 2026-09-20 names the Reserve Bank Integrated Ombudsman Scheme, 2021, which the Reserve Bank has since replaced with the 2026 Scheme, so the circular text is behind the scheme it points at.", "publisher": "Reserve Bank of India", "url": "https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=11946&Mode=0", "source_class": "authoritative_primary", "kind": "circular", "edition": "RBI/2020-21/21, DPSS.CO.PD No.116/02.12.004/2020-21, dated 6 August 2020; the live page as read 2026-09-20", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, fetched and read on 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for the in-upi rail. A RuleSource describes one edition of one document; its status stays draft and a watch dates it through consulted_on. The Reserve Bank's terms of use bar caching and linking to its pages without prior permission, and a request for that permission is on Orca's backlog; the record carries the public address because every Orca record cites its source by address.", "source_edition": "RBI/2020-21/21, DPSS.CO.PD No.116/02.12.004/2020-21, dated 6 August 2020; the live page as read 2026-09-20", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "in-upi:exc.odr-grievance", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:role.customer", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:role.payment-system-participant", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:role.third-party-app-provider", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.dispute-lodging-channels-and-tracking", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.dispute-resolution-minimises-human-judgement", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.dispute-resolution-scope-and-compensation", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.escalation-after-one-month", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.no-upi-app-is-authorised-by-the-reserve-bank", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.ombudsman-scheme-2026-replaced-2021", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.operator-must-run-dispute-resolution", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.tpap-in-app-dispute-lodging", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "in-upi:src.rbi-payment-and-settlement-systems-page", "id": "src.rbi-payment-and-settlement-systems-page", "rail": "in-upi", "class": "RuleSource", "name": "RBI overview page on payment and settlement systems (Board for Regulation and Supervision)", "summary": "The Reserve Bank's older overview of payment systems in India. It states the Payment and Settlement Systems Act position and still calls the Board for Regulation and Supervision of Payment and Settlement Systems the highest policy making body, which the Reserve Bank's other overview page contradicts. Held in the corpus mainly because it disagrees with the Reserve Bank's other overview page about which board governs payment systems. Cite the newer page for the Payments Regulatory Board.", "publisher": "Reserve Bank of India", "url": "https://www.rbi.org.in/Scripts/PaymentSystems_UM.aspx", "source_class": "public_primary", "kind": "web_page", "edition": "live page as read 2026-09-20", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, fetched and read on 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for the in-upi rail. A RuleSource describes one edition of one document; its status stays draft and a watch dates it through consulted_on. The Reserve Bank's terms of use bar caching and linking to its pages without prior permission, and a request for that permission is on Orca's backlog; the record carries the public address because every Orca record cites its source by address.", "source_edition": "live page as read 2026-09-20", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "in-upi:role.rbi", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.authorisation-is-required-to-run-a-payment-system", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.payments-regulatory-board-governs", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "in-upi:src.rbi-payment-systems-overview", "id": "src.rbi-payment-systems-overview", "rail": "in-upi", "class": "RuleSource", "name": "RBI overview page on payment and settlement systems (Payments Regulatory Board and NPCI systems)", "summary": "The Reserve Bank's standing description of the legal frame for payment systems, the Payments Regulatory Board and its members, the systems NPCI operates, and UPI 123Pay for feature phones. A live page the Reserve Bank edits without notice, not a dated instrument.", "publisher": "Reserve Bank of India", "url": "https://www.rbi.org.in/scripts/FS_Overview.aspx?fn=9", "source_class": "public_primary", "kind": "web_page", "edition": "live page as read 2026-09-20", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, fetched and read on 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for the in-upi rail. A RuleSource describes one edition of one document; its status stays draft and a watch dates it through consulted_on. The Reserve Bank's terms of use bar caching and linking to its pages without prior permission, and a request for that permission is on Orca's backlog; the record carries the public address because every Orca record cites its source by address.", "source_edition": "live page as read 2026-09-20", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "in-upi:rail.in-upi", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:role.npci", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:role.payments-regulatory-board", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:role.rbi", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.authorisation-is-required-to-run-a-payment-system", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.finality-not-held", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.hours-not-held", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.interbank-dispute-rules-not-held", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.messages-not-held", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.npci-holds-the-upi-authorisation", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.payments-regulatory-board-governs", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.recall-not-held", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.refund-not-held", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.settlement-not-held", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.transaction-limits-not-held", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:txn.123pay", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "in-upi:src.rbi-tat-circular-2019", "id": "src.rbi-tat-circular-2019", "rail": "in-upi", "class": "RuleSource", "name": "RBI circular on turn around time and customer compensation for failed transactions (RBI/2019-20/67)", "summary": "The Reserve Bank's framework setting, per payment system, how quickly a failed transaction must be reversed and what the customer is paid when it is not. Its Annex carries seven general instructions and a table with one row per system; rows 4(a) and 4(b) are UPI. Addressed to all operators and participants of authorised payment systems. The Reserve Bank edits notification pages in place. Paragraph 6 of the page as read on 2026-09-20 points at the Reserve Bank Integrated Ombudsman Scheme, 2021, a scheme that did not exist when the circular was issued, so the page is the 2019 circular as amended rather than as first published. A watch on this rail must compare the text, not only the reference number and the date.", "publisher": "Reserve Bank of India", "url": "https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=11693&Mode=0", "source_class": "authoritative_primary", "kind": "circular", "edition": "RBI/2019-20/67, DPSS.CO.PD No.629/02.01.014/2019-20, dated 20 September 2019, in effect from 15 October 2019; the live page as read 2026-09-20", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, fetched and read on 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for the in-upi rail. A RuleSource describes one edition of one document; its status stays draft and a watch dates it through consulted_on. The Reserve Bank's terms of use bar caching and linking to its pages without prior permission, and a request for that permission is on Orca's backlog; the record carries the public address because every Orca record cites its source by address.", "source_edition": "RBI/2019-20/67, DPSS.CO.PD No.629/02.01.014/2019-20, dated 20 September 2019, in effect from 15 October 2019; the live page as read 2026-09-20", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "in-upi:rail.in-upi", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:exc.auto-reversal", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:role.beneficiary-bank", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:role.customer", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:role.merchant", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:role.rbi", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:role.remitter-bank", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.auto-reversal-funds-transfer-next-day", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.auto-reversal-merchant-payment-five-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.bank-includes-non-banks", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.compensation-hundred-rupees-a-day", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.compensation-without-a-complaint", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.deadline-is-an-outer-limit", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.dispute-resolution-scope-and-compensation", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.escalation-after-one-month", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.framework-covers-domestic-transactions", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.ombudsman-scheme-2026-replaced-2021", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.transaction-day-and-reversal-day", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.upi-and-imps-are-separate-rows", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:rule.what-counts-as-a-failed-transaction", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:txn.funds-transfer", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "in-upi:txn.merchant-payment", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "in-upi:state.e-mandate-registered", "id": "state.e-mandate-registered", "rail": "in-upi", "class": "LifecycleState", "name": "UPI recurring e-mandate: registered", "summary": "The customer has completed the one-time registration and passed the additional factor of authentication, so the issuer holds a live mandate with a stated validity period. Recurring charges may now be taken under it, each announced at least 24 hours ahead; the first charge needs the additional factor too, unless it was taken together with registration. While registered, the customer may change the validity period, and a variable mandate carries the ceiling the customer chose for any single charge.", "terminal": false, "money_moved": "no", "visible_as": null, "relations": [ { "type": "precedes", "to": "in-upi:state.e-mandate-withdrawn", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "precedes", "to": "in-upi:state.upi-autopay-paused", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "precedes", "to": "in-upi:state.upi-autopay-revoked", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "precedes", "to": "in-upi:state.upi-autopay-expired", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.e-mandate-registration-and-withdrawal", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.upi-autopay-modification", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.upi-autopay-validity-and-expiry", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.e-mandate-first-charge", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.e-mandate-notice-before-each-charge", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-e-mandate-framework-2026", "section": "paragraphs 2, 4(a) to (c), 5(a) and 6(a)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.npci-upi-consolidated-circular-2026", "section": "sections 14.3, 14.5, 14.16 to 14.19, 14.24.6 and 14.24.7", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reserve Bank of India, Digital Payments - E-mandate Framework, 2026 (RBI/DPSS/2026-27/396), paragraphs 2, 4, 5 and 6, read 2026-09-23 on rbi.org.in. The directions speak of a mandate the issuer has registered and give it a validity period, which is what makes registered a state here; they give no status value, so visible_as is null. NPCI's UPI Consolidated Circular version 1.0 (read 2026-09-24) adds three states that can follow this one, paused, revoked and expired, and treats a change of amount, end date or payee UPI ID as leaving the mandate registered; it too names no status value, so visible_as stays null.", "confidence": "medium" }, "currency": { "effective_since": "2026-04-21", "effective_to": null, "effective_note": "Drafted 2026-09-23 by the product view slice 3 drafting session from the document named in basis, opened and read that day. The date is the framework's own, effective immediately on issue, as on the Mandate; UPI e-mandates existed earlier under a January 2020 circular the framework repealed, which was not read.", "source_edition": "RBI/DPSS/2026-27/396, RBI/CO.DPSS.POLC.No.S56/02.14.003/2026-27, dated 21 April 2026; the live page as read 2026-09-23", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-e-mandate-framework-2026", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms registration is a one-time process validated by an additional factor of authentication, that every mandate carries a validity period the issuer must let the customer change at any time after telling them so at registration, that the first recurring charge needs its own additional factor unless combined with registration, and that a variable mandate lets the customer set the largest single charge. Paragraph 2 states the directions cover UPI. Does not address the three NPCI-only states this record links to, paused, revoked and expired, or say that they return the mandate to registered." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:state.upi-autopay-paused", "type": "precedes", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:state.e-mandate-withdrawn", "id": "state.e-mandate-withdrawn", "rail": "in-upi", "class": "LifecycleState", "name": "UPI recurring e-mandate: withdrawn by the customer", "summary": "The customer has taken the mandate back, either through the facility the issuer must offer for withdrawing it at any time or by opting out of the whole mandate from a pre-charge notice. Either way the issuer confirms it with the additional factor of authentication and tells the customer it is done. No further charge may be taken under it. Opting out of a single charge is different: the mandate stays registered.", "terminal": true, "money_moved": "no", "visible_as": null, "relations": [ { "type": "governed_by", "to": "in-upi:rule.e-mandate-registration-and-withdrawal", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.e-mandate-notice-before-each-charge", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "in-upi:state.upi-autopay-revoked", "note": "UPI's own name for the end of a mandate, reached from the merchant's side as well as the customer's", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-e-mandate-framework-2026", "section": "paragraphs 4(b), 4(e) and 6(c)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Reserve Bank of India, Digital Payments - E-mandate Framework, 2026 (RBI/DPSS/2026-27/396), paragraphs 4 and 6, read 2026-09-23 on rbi.org.in. The directions name withdrawal (and head the paragraph revocation) and the opt-out of the mandate, each behind the additional factor; they give no status value, so visible_as is null. That no charge may follow a withdrawal is [Inference] from what withdrawing a standing authorisation means; the directions do not say it in terms. NPCI's UPI Consolidated Circular version 1.0 (read 2026-09-24) calls the end of a mandate revoke, lets it be requested on the merchant's platform too, and there waives the additional factor; that is held in in-upi:state.upi-autopay-revoked, and this record stays the Reserve Bank's customer-side account. The circular names no status value either.", "confidence": "medium" }, "currency": { "effective_since": "2026-04-21", "effective_to": null, "effective_note": "Drafted 2026-09-23 by the product view slice 3 drafting session from the document named in basis, opened and read that day. The date is the framework's own, effective immediately on issue, as on the Mandate.", "source_edition": "RBI/DPSS/2026-27/396, RBI/CO.DPSS.POLC.No.S56/02.14.003/2026-27, dated 21 April 2026; the live page as read 2026-09-23", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.rbi-e-mandate-framework-2026", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms the issuer must offer a facility to withdraw the mandate at any time and a separate facility to opt out of one charge or of the whole mandate from the pre-transaction notice, both validated with an additional factor of authentication and the withdrawal acknowledged to the customer. Does not use the word terminal and does not say in terms that no further charge can follow a withdrawal, though that follows from what withdrawing a standing authorisation means." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:state.e-mandate-registered", "type": "precedes", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:state.upi-autopay-revoked", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:state.upi-autopay-expired", "id": "state.upi-autopay-expired", "rail": "in-upi", "class": "LifecycleState", "name": "UPI AutoPay mandate: expired", "summary": "The mandate's validity period has come to an end, so it is no longer valid and no debit can be taken under it. Nobody has to act for this to happen: the end date set at registration, or changed later by the customer, does it, and no AutoPay mandate can run for more than 30 years. NPCI's list of operations the customer must be told about does not include expiry for AutoPay, so the customer may not hear about it.", "terminal": true, "money_moved": "no", "visible_as": null, "relations": [ { "type": "governed_by", "to": "in-upi:rule.upi-autopay-validity-and-expiry", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.npci-upi-consolidated-circular-2026", "section": "sections 14.3, 14.5 and 14.16; Annexure A, Mandate Validity Period", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPCI/UPI/CC/01 version 1.0 of 18 September 2026, sections 14.3, 14.5 and 14.16 and the Annexure A definition of Mandate Validity Period, read 2026-09-24. The glossary uses the word expired for a mandate past its validity period, but as a description, not as a status value any message or screen carries, so visible_as is null. That an expired mandate cannot come back, which makes the state terminal, is [Inference] from the glossary's calling it invalid; the circular describes no renewal. That the customer may not be told is read from the absence of expiry in section 14.3.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-18", "effective_to": null, "effective_note": "Drafted 2026-09-24 from NPCI's UPI Consolidated Circular version 1.0, read from a copy Dave saved from npci.org.in on 2026-09-23 because that host refuses automated requests. The date is the circular's issue date. The circular consolidates Operating Circulars issued up to 31 July 2026 and says it changes none of their effective dates; those circulars were not read, so the state may have existed earlier.", "source_edition": "NPCI/UPI/CC/01, UPI Consolidated Circular version 1.0, issued 18 September 2026; copy saved 2026-09-23", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.npci-upi-consolidated-circular-2026", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms every mandate carries a validity period the payee PSP must cap at 30 years, that section 14.5 lets the customer set or edit the end date at registration and section 14.16 lets the customer's bank change it afterward, and that the Annexure A glossary defines Mandate Validity Period as ending with the mandate deemed expired and invalid, with no act required by either side. Confirms expiry is absent from the list of AutoPay events section 14.3 requires to be notified, unlike section 16.11's own notification duty for UPI Reserve Pay, which does name expiry." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:state.e-mandate-registered", "type": "precedes", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:state.upi-autopay-paused", "type": "precedes", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:state.upi-autopay-paused", "id": "state.upi-autopay-paused", "rail": "in-upi", "class": "LifecycleState", "name": "UPI AutoPay mandate: paused", "summary": "The customer has put the mandate on hold, so the debit it would otherwise produce does not go ahead, but the mandate itself survives. NPCI counts opting out of one particular debit as this same pause. The customer can get here from their bank, from their UPI app (unless the mandate is for loan payments or EMI collection) or through UPI HELP, and is told by SMS and in the app. Lifting the pause, which NPCI calls unpause or resume, returns the mandate to its registered state; it can also still be revoked, and it lapses anyway if its validity period runs out.", "terminal": false, "money_moved": "no", "visible_as": null, "relations": [ { "type": "precedes", "to": "in-upi:state.e-mandate-registered", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "precedes", "to": "in-upi:state.upi-autopay-revoked", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "precedes", "to": "in-upi:state.upi-autopay-expired", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.upi-autopay-pause-and-unpause", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.upi-autopay-every-mandate-event-is-notified", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.npci-upi-consolidated-circular-2026", "section": "sections 14.3, 14.18 to 14.20 and 33.4", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "NPCI/UPI/CC/01 version 1.0 of 18 September 2026, sections 14.3, 14.18 to 14.20 and 33.4, read 2026-09-24. The circular names pause and unpause as mandate operations, each notified, and resume as an action in UPI HELP; it gives no status value, so visible_as is null. That pause is a state of the mandate, rather than a skip applied to one debit only, is Orca's reading: section 14.18 treats the two as one facility and section 14.3 lists unpause as an operation of its own, which only makes sense if the pause persists until lifted. How long a pause may last, whether it covers more than one debit, and that a paused mandate can be revoked or expire, are [Inference]; the circular does not say.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-18", "effective_to": null, "effective_note": "Drafted 2026-09-24 from NPCI's UPI Consolidated Circular version 1.0, read from a copy Dave saved from npci.org.in on 2026-09-23 because that host refuses automated requests. The date is the circular's issue date. The circular consolidates Operating Circulars issued up to 31 July 2026 and says it changes none of their effective dates; those circulars were not read, so the state may have existed earlier.", "source_edition": "NPCI/UPI/CC/01, UPI Consolidated Circular version 1.0, issued 18 September 2026; copy saved 2026-09-23", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "in-upi:state.e-mandate-registered", "type": "precedes", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:state.upi-autopay-revoked", "id": "state.upi-autopay-revoked", "rail": "in-upi", "class": "LifecycleState", "name": "UPI AutoPay mandate: revoked", "summary": "The mandate has been ended through the UPI AutoPay channel and no further debit may be taken under it. This is UPI's own name for the end of a mandate, whichever side the request came from: the customer's bank, the customer's UPI app (not offered there for loan payments or EMI collection), UPI HELP, or the merchant's own website or app. A request made on the merchant's platform must be passed into the AutoPay channel, so the mandate ends at the bank as well, and it needs no additional factor of authentication under UPI's rules. The customer is told by SMS and in the app. Any member that later finds an operation failing because the mandate is revoked deletes its own copy. The Reserve Bank's withdrawal by the customer is one way of reaching this state.", "terminal": true, "money_moved": "no", "visible_as": null, "relations": [ { "type": "governed_by", "to": "in-upi:rule.upi-autopay-revocation", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "in-upi:rule.upi-autopay-every-mandate-event-is-notified", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "in-upi:state.e-mandate-withdrawn", "note": "the Reserve Bank's name for the customer-initiated case, with its additional factor of authentication", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.npci-upi-consolidated-circular-2026", "section": "sections 14.3, 14.18, 14.19, 14.21 to 14.23 and 33.4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "NPCI/UPI/CC/01 version 1.0 of 18 September 2026, sections 14.3, 14.18, 14.19, 14.21 to 14.23 and 33.4, read 2026-09-24. The circular names revoke as a mandate operation and speaks of a mandate having been revoked; it gives no status value, so visible_as is null. That a revoked mandate cannot be revived, which makes the state terminal, is [Inference]: the circular describes no reinstatement and section 14.22 has members delete it. How this state relates to in-upi:state.e-mandate-withdrawn is Orca's reading, not the circular's: both describe the end of the mandate, the Reserve Bank's text naming only the customer's route and requiring the additional factor, NPCI's naming every route and waiving the factor on the merchant's platform. The two records are kept apart because they rest on different authorities and disagree on that point.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-18", "effective_to": null, "effective_note": "Drafted 2026-09-24 from NPCI's UPI Consolidated Circular version 1.0, read from a copy Dave saved from npci.org.in on 2026-09-23 because that host refuses automated requests. The date is the circular's issue date. The circular consolidates Operating Circulars issued up to 31 July 2026 and says it changes none of their effective dates; those circulars were not read, so the state may have existed earlier.", "source_edition": "NPCI/UPI/CC/01, UPI Consolidated Circular version 1.0, issued 18 September 2026; copy saved 2026-09-23", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "in-upi:src.npci-upi-consolidated-circular-2026", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms revoke as a named mandate operation reachable from the customer's bank under section 14.18, the customer's UPI app except on Loan Payments and EMI Collection mandates under section 14.19, UPI HELP under section 33.4, and the merchant's own website or app under section 14.21, with a merchant-side request required to travel through the UPI AutoPay channel so the mandate ends everywhere rather than only in the merchant's own records. Confirms section 14.23 waives the additional factor of authentication for a withdrawal made through the merchant platform, section 14.22 requires a member that finds an operation failing because the mandate is revoked or missing to remove its own copy, and revoke is on the section 14.3 list of events notified by SMS and app. Does not state that a revoked mandate can never be reinstated. The relation this record draws to in-upi:state.e-mandate-withdrawn is Orca's own reading and this circular does not address it." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:state.e-mandate-registered", "type": "precedes", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:state.e-mandate-withdrawn", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:state.upi-autopay-paused", "type": "precedes", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:txn.123pay", "id": "txn.123pay", "rail": "in-upi", "class": "TransactionType", "name": "UPI 123Pay, a UPI payment from a feature phone", "summary": "UPI for people without a smartphone, which the Reserve Bank describes as an instant payment system for feature phone users reachable four ways: an interactive voice response number, a missed call, a function built into the handset by its maker, and a proximity sound based method. The Reserve Bank names it as a distinct offering. Which UPI rules hold for it, and which do not, is NPCI's to say and is not held.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-payment-systems-overview", "section": "Digital payment options for feature phone users (UPI 123Pay)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "The RBI payment systems overview page, read 2026-09-20. The page describes the offering and does not state its rules, so the record is low confidence beyond its existence.", "confidence": "low" }, "currency": { "effective_since": "Unknown: the page read does not date UPI 123Pay", "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 nothing here rests on UPI's own scheme rules.", "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": "in-upi:src.rbi-payment-systems-overview", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms UPI 123Pay as a feature phone payment service reachable by IVR, missed call, OEM handset functionality and proximity sound based technology." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:rule.two-factors-of-authentication", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:txn.funds-transfer", "id": "txn.funds-transfer", "rail": "in-upi", "class": "TransactionType", "name": "UPI transfer of funds to another person", "summary": "A UPI payment from one person's account to another's, which the Reserve Bank's turn around time framework treats as its own case: the payer's account is debited and the payee's account is to be credited. It carries the shorter of UPI's two reversal clocks. How the payment is addressed, authorised and carried is NPCI's to define and is not held.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-tat-circular-2019", "section": "Annex, row 4(a)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "RBI/2019-20/67, Annex row 4(a), read 2026-09-20. sec_code is null: UPI has no entry class code that any document read names.", "confidence": "medium" }, "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 nothing here rests on UPI's own scheme rules.", "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": "in-upi:src.rbi-tat-circular-2019", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the funds transfer case as its own annex row with the day after reversal deadline." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:rule.auto-reversal-funds-transfer-next-day", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.compensation-hundred-rupees-a-day", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.dispute-resolution-scope-and-compensation", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.two-factors-of-authentication", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:txn.merchant-payment", "id": "txn.merchant-payment", "rail": "in-upi", "class": "TransactionType", "name": "UPI payment to a merchant", "summary": "A UPI payment for goods or services, which the Reserve Bank's turn around time framework separates from a transfer to another person and gives the longer reversal clock: the payer's account is debited and no confirmation of the transaction reaches the merchant. A tap and pay at a near field communication terminal is exempt from two factor authentication under a Reserve Bank letter to NPCI.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-tat-circular-2019", "section": "Annex, row 4(b)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-authentication-directions-2025", "section": "Annexure-1, item 7", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "RBI/2019-20/67 Annex row 4(b) and RBI/2025-26/79 Annexure-1 item 7, read 2026-09-20. sec_code is null.", "confidence": "medium" }, "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 nothing here rests on UPI's own scheme rules.", "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": "in-upi:src.rbi-tat-circular-2019", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the merchant payment case as a separate annex row with the five day reversal deadline." }, { "source": "in-upi:src.rbi-authentication-directions-2025", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the tap and pay near field communication exemption at Annexure-1 item 7." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:rule.authentication-exemptions-include-upi-tap-and-pay", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.auto-reversal-merchant-payment-five-days", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.compensation-hundred-rupees-a-day", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.dispute-resolution-scope-and-compensation", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.two-factors-of-authentication", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "in-upi:txn.recurring", "id": "txn.recurring", "rail": "in-upi", "class": "TransactionType", "name": "Recurring UPI payment taken under a mandate", "summary": "A payment taken again and again from the customer's account on a standing authorisation. The Reserve Bank's recurring payment framework says in its own applicability paragraph that it covers recurring transactions made using UPI, and sets how the mandate is registered and withdrawn, what notice the customer gets before and after each charge, and above what amount the customer must authenticate again.", "sec_code": null, "directions": [ "debit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "in-upi:src.rbi-e-mandate-framework-2026", "section": "paragraph 2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "in-upi:src.rbi-authentication-directions-2025", "section": "Annexure-1, item 2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "RBI/DPSS/2026-27/396 paragraph 2 and RBI/2025-26/79 Annexure-1 item 2, read 2026-09-20. sec_code is null. Direction is debit because the framework describes the issuer charging or debiting the customer's account; how UPI carries that is NPCI's and is not held.", "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 nothing here rests on UPI's own scheme rules.", "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": "in-upi:src.rbi-e-mandate-framework-2026", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the framework's applicability to recurring UPI transactions, and its registration, notice and authentication threshold provisions." }, { "source": "in-upi:src.rbi-authentication-directions-2025", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms recurring transactions after the first as an authentication exemption item at Annexure-1 item 2." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:mandate.upi-recurring", "type": "authorises", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.authentication-exemptions-include-upi-tap-and-pay", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.e-mandate-authentication-threshold", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.e-mandate-costs-the-customer-nothing", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.e-mandate-disputes-and-liability", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.e-mandate-first-charge", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.e-mandate-framework-covers-upi", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.e-mandate-higher-threshold-for-three-categories", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.e-mandate-notice-after-each-charge", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.e-mandate-notice-before-each-charge", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.e-mandate-registration-and-withdrawal", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.two-factors-of-authentication", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.upi-autopay-every-mandate-event-is-notified", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.upi-autopay-modification", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.upi-autopay-pause-and-unpause", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.upi-autopay-revocation", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:rule.upi-autopay-validity-and-expiry", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "in-upi:rule.compensation-without-a-complaint", "in-upi:rule.operator-must-run-dispute-resolution", "in-upi:rule.dispute-resolution-scope-and-compensation", "in-upi:rule.dispute-lodging-channels-and-tracking", "in-upi:rule.tpap-in-app-dispute-lodging", "in-upi:rule.escalation-after-one-month", "in-upi:rule.ombudsman-scheme-2021-covers-system-participants", "in-upi:rule.ombudsman-scheme-2026-replaced-2021", "in-upi:rule.ombudsman-when-a-complaint-may-be-filed", "in-upi:rule.alerts-and-channels-for-reporting", "in-upi:rule.two-factors-of-authentication", "in-upi:rule.authentication-exemptions-include-upi-tap-and-pay", "in-upi:rule.e-mandate-registration-and-withdrawal", "in-upi:rule.e-mandate-notice-before-each-charge", "in-upi:rule.e-mandate-notice-after-each-charge", "in-upi:rule.e-mandate-first-charge", "in-upi:rule.e-mandate-costs-the-customer-nothing" ], "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.", "relations": [ { "type": "see_also", "to": "in-upi:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "in-upi:decision-points", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "in-upi:src.rbi-odr-circular-2020", "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": "in-upi:src.rbi-integrated-ombudsman-faq-2026", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the free, 90 day, 30 day wait ombudsman route." }, { "source": "in-upi:src.rbi-authentication-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": "in-upi:src.rbi-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:consumer-law", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:decision-points", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:liability", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:limits", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "in-upi:rule.dispute-resolution-minimises-human-judgement", "in-upi:rule.compensation-without-a-complaint", "in-upi:rule.limited-liability-for-the-customer", "in-upi:rule.risk-based-checks-above-the-minimum", "in-upi:rule.ombudsman-how-a-complaint-ends", "in-upi:rule.interbank-dispute-rules-not-held" ], "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.", "relations": [ { "type": "see_also", "to": "in-upi:consumer-law", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "in-upi:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "in-upi:src.rbi-odr-circular-2020", "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": "in-upi:src.rbi-customer-liability-circular-2017", "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": "in-upi:src.rbi-authentication-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": "in-upi:src.rbi-integrated-ombudsman-faq-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:consumer-law", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:participants", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "in-upi:rule.finality-not-held", "in-upi:rule.npci-holds-the-upi-authorisation", "in-upi:rule.auto-reversal-funds-transfer-next-day" ], "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.", "relations": [ { "type": "see_also", "to": "in-upi:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "in-upi:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "in-upi:src.rbi-certificates-of-authorisation-2026-09-08", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:recall", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:settlement", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "in-upi:rule.hours-not-held", "in-upi:rule.npci-holds-the-upi-authorisation" ], "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.", "relations": [ { "type": "see_also", "to": "in-upi:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "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.", "rules": [ "in-upi:rule.compensation-hundred-rupees-a-day", "in-upi:rule.zero-liability-for-the-customer", "in-upi:rule.limited-liability-for-the-customer", "in-upi:rule.money-back-within-ten-working-days", "in-upi:rule.claim-settled-within-ninety-days", "in-upi:rule.bank-must-prove-the-customer-is-liable", "in-upi:rule.issuer-pays-in-full-for-bad-authentication", "in-upi:rule.e-mandate-disputes-and-liability", "in-upi:rule.ombudsman-costs-nothing-and-what-it-can-award" ], "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.", "relations": [ { "type": "see_also", "to": "in-upi:consumer-law", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "in-upi:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "in-upi:src.rbi-customer-liability-circular-2017", "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": "in-upi:src.rbi-authentication-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": "in-upi:src.rbi-integrated-ombudsman-faq-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:liability", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:consumer-law", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:decision-points", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:return", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "in-upi:rule.e-mandate-authentication-threshold", "in-upi:rule.e-mandate-higher-threshold-for-three-categories", "in-upi:rule.transaction-limits-not-held" ], "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.", "relations": [ { "type": "see_also", "to": "in-upi:consumer-law", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "in-upi:src.rbi-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "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.", "rules": [ "in-upi:rule.messages-not-held", "in-upi:rule.upi-and-imps-are-separate-rows", "in-upi:rule.npci-holds-the-upi-authorisation" ], "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.", "relations": [ { "type": "see_also", "to": "in-upi:participants", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "in-upi:src.rbi-certificates-of-authorisation-2026-09-08", "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": "in-upi:src.rbi-tat-circular-2019", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:participants", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "in-upi:rule.authorisation-is-required-to-run-a-payment-system", "in-upi:rule.npci-holds-the-upi-authorisation", "in-upi:rule.no-upi-app-is-authorised-by-the-reserve-bank", "in-upi:rule.payments-regulatory-board-governs", "in-upi:rule.bank-includes-non-banks", "in-upi:rule.upi-and-imps-are-separate-rows", "in-upi:rule.authentication-must-be-open-to-all-applications", "in-upi:rule.e-mandate-framework-covers-upi" ], "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.", "relations": [ { "type": "see_also", "to": "in-upi:decision-points", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "in-upi:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "in-upi:role.payments-regulatory-board", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:messages", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "in-upi:rule.recall-not-held", "in-upi:rule.auto-reversal-funds-transfer-next-day", "in-upi:rule.e-mandate-registration-and-withdrawal", "in-upi:rule.e-mandate-notice-before-each-charge" ], "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.", "relations": [ { "type": "see_also", "to": "in-upi:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "in-upi:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "in-upi:src.rbi-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": "in-upi:src.rbi-tat-circular-2019", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:finality", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:return", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "in-upi:rule.refund-not-held", "in-upi:rule.auto-reversal-merchant-payment-five-days" ], "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.", "relations": [ { "type": "see_also", "to": "in-upi:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "in-upi:src.rbi-tat-circular-2019", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:return", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "in-upi:rule.auto-reversal-funds-transfer-next-day", "in-upi:rule.auto-reversal-merchant-payment-five-days", "in-upi:rule.transaction-day-and-reversal-day", "in-upi:rule.what-counts-as-a-failed-transaction", "in-upi:rule.deadline-is-an-outer-limit", "in-upi:rule.compensation-hundred-rupees-a-day", "in-upi:rule.compensation-without-a-complaint", "in-upi:rule.framework-covers-domestic-transactions", "in-upi:rule.upi-and-imps-are-separate-rows", "in-upi:rule.interbank-dispute-rules-not-held" ], "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.", "relations": [ { "type": "see_also", "to": "in-upi:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "in-upi:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "in-upi:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "in-upi:src.rbi-tat-circular-2019", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "in-upi:finality", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:liability", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:recall", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:refund", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "in-upi:rule.settlement-not-held", "in-upi:rule.npci-holds-the-upi-authorisation" ], "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.", "relations": [ { "type": "see_also", "to": "in-upi:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "in-upi:src.rbi-certificates-of-authorisation-2026-09-08", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:settlement", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "in-upi:hours", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "mx-spei:rail.mx-spei", "id": "rail.mx-spei", "class": "Rail", "rail": "mx-spei", "name": "SPEI (Mexico peso interbank electronic transfers)", "governing_authority": "Banco de México", "country": "MX", "currency": "MXN", "operators": [ "Banco de México, as Administrador del SPEI under Ley de Sistemas de Pagos article 2, fracción I" ], "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Í" ], "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Reglas 1a, 3a, 18a, 23a, 24a, 35a, 56a and 57a", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "mx-spei:src.ley-sistemas-de-pagos", "section": "articles 2, 4, 6 and 11", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "mx-spei:src.participantes-directos", "section": "listado público updated 2026-09-10", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "source_class": null, "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:exc.devolucion-acreditada", "id": "exc.devolucion-acreditada", "rail": "mx-spei", "class": "Exception", "name": "Devolución of a transfer already credited to a customer account", "summary": "A payment that reached the beneficiary's account goes back only as a new transfer order of the credited return type. The beneficiary may start it by presenting a Solicitud de Envío for a payment it does not recognise, and the receiving participant must send it within thirty seconds of that request, four seconds for CoDi. The participant must also send one without the beneficiary asking where the Convenio de Colaboración says the funds must go back, or where it did not send the CoDi credit advice, in which case the deadline runs from the settlement advice and is eight seconds. A return sent on a later operating day is the extemporánea type. The sending participant credits its own customer within thirty seconds, four for CoDi, and tells the customer within five seconds of crediting.", "money_moves": true, "outcome": "Funds move back from the beneficiary's side to the payer's side as a fresh settled transfer order, through the instance the original used save in the cases section 5.16.4 of the Manual allows. Where the sending participant cannot credit its customer it must not send the money back again; it must make the funds available for withdrawal at a counter or transfer to another account the customer names.", "relations": [ { "type": "initiated_by", "to": "mx-spei:role.cliente-beneficiario", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "initiated_by", "to": "mx-spei:role.participante-receptor", "note": "Under Regla 28a the receiving participant must send the return without the beneficiary asking where the Convenio de Colaboración so determines or where it failed to send the CoDi credit advice.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "mx-spei:role.participante-receptor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "follows", "to": "mx-spei:exc.solicitud-de-apoyo", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Reglas 28a, 29a, 30a and 31a", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 28a, 29a, 30a and 31a, 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 from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Reglas 28a to 31a: a credited payment returns only as a new credited return order, started by the beneficiary within thirty seconds or four for CoDi, or by the receiving participant on its own under the Convenio or a missed CoDi credit advice at eight seconds, with a later return becoming the extemporanea type and the sending participant crediting within thirty or four seconds and telling the customer within five." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "mx-spei:rule.abono-de-la-devolucion-acreditada", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.devolucion-acreditada-extemporanea", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.devolucion-de-transferencia-acreditada", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "mx-spei:exc.devolucion-no-acreditada", "id": "exc.devolucion-no-acreditada", "rail": "mx-spei", "class": "Exception", "name": "Devolución of a transfer not credited to a customer account", "summary": "The receiving participant sends a new transfer order of the return type back through the same SPEI instance, stating the cause from the numbered catalogue in section 9 of the Manual, which Orca does not hold. Sixty seconds from the settlement advice is the general deadline, ten seconds for a low value order in the 06:00:00 to 17:59:50 window, eight seconds for a CoDi order at any hour of any day, and 06:00:10 or 06:01:00 for orders taken overnight; participant to participant orders are exempt. A return sent on a later operating day is the extemporánea type and its amount must include the Regla 87a compensation. The sending participant credits its own customer within five seconds of the return's settlement advice, four for CoDi, and tells the customer the cause within five seconds of crediting.", "money_moves": true, "outcome": "The receiving participant must return on any of the ten grounds in Regla 23a: information that does not meet section 8 of the Manual, a non-existent beneficiary account, a transfer identified as presumed fraudulent under the Convenio, a judicial or administrative block on the account, an optional order type the participant told the Administrador it would not take, a non-scheduled payment reaching an alternate account, no pre-agreed sweep account under Regla 70a, any further cause the Manual's section 9 marks as such, a CoDi order outside the permitted cases, and a Clave de Rastreo the same sender already used on that operation date.", "relations": [ { "type": "initiated_by", "to": "mx-spei:role.participante-receptor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "mx-spei:role.participante-receptor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Reglas 23a, 24a, 25a, 25a Bis, 26a and 27a", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 23a, 24a, 25a, 25a Bis, 26a and 27a, 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 from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Reglas 23a to 27a and 25a Bis: the receiving participant returns through the same instance stating a Manual section 9 cause, on the deadlines and exemptions the record lists, with a late return becoming the extemporanea type carrying the Regla 87a compensation, and the sending participant crediting within five or four seconds and telling the customer the cause." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "mx-spei:rule.abono-de-la-devolucion-no-acreditada", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.aviso-de-la-causa-al-cliente-emisor", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.catalogo-de-causas-de-devolucion-no-publico", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.causas-de-devolucion-no-acreditada", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.devolucion-extemporanea-lleva-la-compensacion", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.plazo-de-devolucion-no-acreditada", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.reintento-de-una-devolucion-eliminada", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "mx-spei:exc.eliminacion", "id": "exc.eliminacion", "rail": "mx-spei", "class": "Exception", "name": "Elimination of an unsettled transfer order by the Administrador", "summary": "An order the Administrador cannot settle is not queued indefinitely. It is eliminated automatically when it is still unsettled at the close of the operating day, when it has run out the number of clearing cycles section 5.7 of the Manual sets because the sender's Cuenta del SPEI is short or the receiving participant is disconnected, when a CoDi order is unsettled after the clearing cycle following its receipt, or when the Administrador is prevented from processing it. The Administrador may also eliminate orders while the sender has insufficient balance in the relevant instance account.", "money_moves": false, "outcome": "No money moves and the payment does not happen. The sending participant must tell its customer within ten seconds of the Administrador's message, through the channel the request came in on and the additional channel they agreed. For eliminations on the insufficient balance, disconnection or Administrador impediment grounds the participant may let the customer submit the request again, under a new Clave de Rastreo and a fresh identity check. A participant may charge for a retry only when the retry succeeds, and never for the eliminated order itself.", "relations": [ { "type": "decided_by", "to": "mx-spei:role.banco-de-mexico", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 17a, fracciones I to IV and the paragraphs that follow, and Regla 88a", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 17a and 88a, 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 from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 17a's four elimination grounds and the insufficient balance ground, that the sending participant must notify its customer within ten seconds of the Administrador's message, that a fresh request under a new Clave de Rastreo is allowed on some grounds, and that Regla 88a bars a fee for the eliminated order and allows one for a successful retry only." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "mx-spei:rule.eliminacion-de-ordenes-no-liquidadas", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.reintento-de-una-devolucion-eliminada", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "mx-spei:exc.solicitud-de-apoyo", "id": "exc.solicitud-de-apoyo", "rail": "mx-spei", "class": "Exception", "name": "Solicitud de apoyo under the Convenio de Colaboración", "summary": "The path for a payer whose account was debited for a transfer it did not instruct. Regla 43a makes the 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. The Convenio itself is not published. Regla 43a sets what it must contain: how the receiving participant handles and follows up a request and keeps the evidence, the criteria and times for accepting or rejecting it, how and for how long the beneficiary may 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 responsibilities and disputes between participants are settled.", "money_moves": false, "outcome": "The request itself moves no money; it is an inter-participant claim. Where it succeeds, or where the participants have enough to presume a fraudulent operation, the money comes back as a devolución of a credited transfer under Reglas 28a or 29a, or as a devolución of a transfer not credited under Regla 24a where the receiving participant caught it before crediting. Whether a request is accepted, and how long the beneficiary's access is restricted, are decided by criteria in a document Orca does not hold.", "relations": [ { "type": "initiated_by", "to": "mx-spei:role.participante-emisor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "mx-spei:role.participante-receptor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Reglas 23a, fracción III, 28a and 43a", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 23a fracción III, 28a and 43a, read 2026-09-20. The Convenio's own content is unknown: it is approved by Banco de México but not published.", "confidence": "medium" }, "currency": { "effective_since": "2022-03-23", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 43a requires the Convenio de Colaboracion, with Banco de Mexico's prior authorisation, and sets its required contents as the record lists, and that Reglas 23a fraccion III and 28a route a presumed fraudulent transfer to a not credited or credited return depending on when it is caught. The Convenio's own text is not public and was not consulted." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "mx-spei:exc.devolucion-acreditada", "type": "follows", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.convenio-de-colaboracion-obligatorio", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "mx-spei:role.banco-de-mexico", "id": "role.banco-de-mexico", "rail": "mx-spei", "class": "Role", "name": "Banco de México (Administrador del SPEI)", "summary": "One institution writes the rules, runs the system and settles it. Banco de México is the Administrador del SPEI under Ley de Sistemas de Pagos article 2, fracción I: it issues the Reglas by circular, prepares the Manual, publishes the Guías, keeps every participant's Cuenta del SPEI, validates and settles each Orden de Transferencia and issues the Aviso de Liquidación. It also admits and suspends participants, authorises the fraud collaboration agreement, may extend or suspend the operating hours, and charges the SPEI quotas. There is no scheme owner, operator or association between it and the participants. kind is operator because running and settling the system is its main function here; it is equally the governing authority and the settlement bank, which Role.kind cannot say at once.", "kind": "operator", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Reglas 2a, fracción I, 6a, 18a, 22a, 36a, 43a, 64a, 81a and 90a", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "mx-spei:src.ley-sistemas-de-pagos", "section": "article 2, fracción I, and article 4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "mx-spei:src.spei-pfmi", "section": "executive summary and section III.A", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 2a fracción I, 6a, 18a, 22a, 36a, 43a, 64a and 90a; Ley de Sistemas de Pagos articles 2 and 4; SPEI PFMI disclosure of 2016-03-28, executive summary; 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 from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 14/2017, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified]. The PFMI lines carry the disclosure's own date of 2016-03-28.", "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; 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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 2a fraccion I defines the Administrador as Banco de Mexico, and Reglas 6a, 18a, 22a, 36a, 43a, 64a and 90a give it the settlement, hours extension, Convenio authorisation, admission and quota functions the record states." }, { "source": "mx-spei:src.ley-sistemas-de-pagos", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms article 2 fraccion I defines Administrador del Sistema and article 4 makes Banco de Mexico publish the January designation list, matching the record's statutory basis." }, { "source": "mx-spei:src.spei-pfmi", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms the executive summary and section III.A describe Banco de Mexico as the single institution that issues the Reglas, administers SPEI and settles it, consistent with the record's one institution claim." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "mx-spei:exc.eliminacion", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.ampliacion-o-suspension-del-horario", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.autorizacion-admision-y-contrato", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.dia-de-operacion-del-spei", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.el-administrador-queda-liberado", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.eliminacion-de-ordenes-no-liquidadas", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.guias-de-homologacion-obligatorias", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.liquidacion-contra-el-saldo-de-la-instancia", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.orden-aceptada-por-spei", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "mx-spei:role.cliente-beneficiario-indirecto", "id": "role.cliente-beneficiario-indirecto", "rail": "mx-spei", "class": "Role", "name": "Cliente Beneficiario Indirecto (beneficiary customer of an indirect participant)", "summary": "The customer of a Participante Indirecto whose account is credited. The receiving participant credits the indirect participant's Cuenta del Cliente and must make sure the indirect participant credits this customer for the same amount. The information the Reglas require reaches this customer through the indirect participant, and Regla 83a, fracción IV, sets what the participant must pass down for that purpose.", "kind": "party", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Reglas 9a Bis 4, 19a, second paragraph, 20a Bis and 83a, fracción IV", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 9a Bis 4, 19a second paragraph, 20a Bis and 83a fracción IV, read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2025-02-21", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 2/2025, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 9a Bis 4, Regla 19a second paragraph, Regla 20a Bis and Regla 83a fraccion IV: an indirect participant's beneficiary customer is credited by the receiving participant crediting the indirect participant's own Cuenta del Cliente first, and information reaches this customer through the indirect participant." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:role.cliente-beneficiario", "id": "role.cliente-beneficiario", "rail": "mx-spei", "class": "Role", "name": "Cliente Beneficiario (beneficiary customer)", "summary": "The holder of the Cuenta del Cliente named in the transfer order as the account to be credited, and the person who generates a Mensaje de Cobro in the CoDi flow. A beneficiary who does not recognise a credited payment may present a Solicitud de Envío for a devolución of a credited transfer, which is the only customer started return on this rail. The beneficiary is entitled to the transfer information, to be told why a settled payment was not credited, and to a free channel for asking.", "kind": "party", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Reglas 2a, fracción X, 19a, 28a, 83a and 84a, fracciones IV and V", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 2a fracción X, 19a, 28a, 83a and 84a fracciones IV and V, 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 from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 2a fraccion X defines Cliente Beneficiario as the Cuenta del Cliente holder named to receive funds or who generates Mensajes de Cobro, and Reglas 19a, 28a, 83a and 84a give this customer crediting, credited-return-instructing and information rights as the record states." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "mx-spei:exc.devolucion-acreditada", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.devolucion-de-transferencia-acreditada", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "mx-spei:role.cliente-emisor-indirecto", "id": "role.cliente-emisor-indirecto", "rail": "mx-spei", "class": "Role", "name": "Cliente Emisor Indirecto (paying customer of an indirect participant)", "summary": "The customer of a Participante Indirecto who instructs a transfer. The instruction goes to the indirect participant, which passes it to its participant as a Solicitud de Envío. The Reglas give this customer the same information, crediting and delay compensation entitlements as a Cliente Emisor, but they reach it through the Contrato de Servicios de Participación Indirecta rather than directly, and the participant must verify that the indirect participant performs them.", "kind": "party", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Reglas 9a Bis 4, 9a Bis 10, 27a, 31a and 86a, fracciones I Bis and III Bis", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 9a Bis 4, 9a Bis 10, 27a, 31a and 86a fracciones I Bis and III Bis, 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 from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 9a Bis 4 and 9a Bis 10 route an indirect paying customer's instruction through the indirect participant as a Solicitud de Envio, and Reglas 27a, 31a and 86a fracciones I Bis and III Bis extend the same information, crediting and compensation entitlements down through the Contrato de Servicios de Participacion Indirecta." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:role.cliente-emisor", "id": "role.cliente-emisor", "rail": "mx-spei", "class": "Role", "name": "Cliente Emisor (paying customer)", "summary": "The holder of a Cuenta del Cliente at the sending participant who presents the Solicitud de Envío. The customer chooses the beneficiary account identifier, the amount, the concept and the Referencia Numérica, and is entitled to the transfer information, the CEP link, notice of a devolución and its cause, and the delay compensation when a deadline is missed. Nothing in the Reglas gives the customer a unilateral right to pull back a settled payment.", "kind": "party", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Reglas 2a, fracción XII, 10a, 12a, 27a, 31a, 83a and 86a", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 2a fracción XII, 10a, 12a, 27a, 31a, 83a and 86a, 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 from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 2a fraccion XII, and Reglas 10a, 12a, 27a, 31a, 83a and 86a: the paying customer presents the Solicitud de Envio, chooses the beneficiary identifier, amount, concept and Referencia Numerica, and is entitled to information, notice of a return and its cause, and delay compensation, with no unilateral right to pull back a settled payment." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:role.participante-emisor", "id": "role.participante-emisor", "rail": "mx-spei", "class": "Role", "name": "Participante Emisor (sending participant)", "summary": "The participant that accepts a customer's Solicitud de Envío and sends the resulting Orden de Transferencia to the Administrador. It verifies and decides whether to accept the request, sends within thirty seconds of accepting, or five seconds where it is a credit institution or a mobile transfer clearing house and four seconds for a CoDi order accepted from a Mensaje de Cobro, may instruct cancellation while the order is unsettled, credits its customer when a devolución comes back, tells the customer the cause, and pays the delay compensation when it misses a deadline.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Reglas 2a, fracción XXXVII, 13a, 17a, 27a, 31a and 86a", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 2a fracción XXXVII, 13a, 17a, 27a, 31a and 86a, 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 from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 2a fraccion XXXVII and Reglas 13a, 17a, 27a, 31a and 86a: the sending participant verifies and decides on the Solicitud de Envio, sends within the Regla 17a deadlines, may cancel before settlement, credits a return, tells the customer the cause, and pays delay compensation when it misses a deadline." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "mx-spei:exc.solicitud-de-apoyo", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.abono-de-la-devolucion-acreditada", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.abono-de-la-devolucion-no-acreditada", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.aviso-de-falla-en-sesenta-segundos", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.aviso-de-la-causa-al-cliente-emisor", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.calculo-de-la-compensacion-por-demora", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.canales-y-plazos-de-la-informacion", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.cancelacion-solo-antes-de-la-liquidacion", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.clave-de-rastreo-y-referencia-numerica", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.compensacion-por-demora-al-cliente", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.compensacion-por-demora-entre-participantes", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.convenio-de-colaboracion-obligatorio", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.cuotas-del-spei", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.datos-a-confirmar-antes-de-autorizar", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.datos-en-la-notificacion-del-resultado", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.el-emisor-verifica-y-decide-aceptar-la-solicitud", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.fondeo-de-las-cuentas-del-spei", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.guias-de-homologacion-obligatorias", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.informacion-de-la-transferencia-al-cliente", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.nombre-del-participante-receptor-desde-el-identificador", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.pagina-de-aclaraciones-y-reclamaciones", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.sin-comisiones-por-enviar-recibir-devolver-o-abonar", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.sin-sobregiros-en-la-cuenta-del-spei", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.suspension-de-solicitudes-durante-una-falla", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.vinculo-al-cep-en-cinco-minutos", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "mx-spei:role.participante-indirecto", "id": "role.participante-indirecto", "rail": "mx-spei", "class": "Role", "name": "Participante Indirecto (indirect participant)", "summary": "A customer of a participant that, under a Contrato de Servicios de Participación Indirecta, passes transfers to and from its own Clientes Emisores Indirectos and Clientes Beneficiarios Indirectos through that participant. It is not a Participante and holds no Cuenta del SPEI. Reglas 9a Bis 1 to 9a Bis 10 set who may be one, who is excluded, what the contract must contain and how the service is suspended or ended, and the contract pushes the participant's own obligations, including the crediting deadlines and the delay compensation, down onto it.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Reglas 2a, fracción XXXVII Bis, 9a Bis 1 to 9a Bis 10, 19a and 86a", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 2a fracción XXXVII Bis, 9a Bis 1 to 9a Bis 10, 19a and 86a, 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 from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 2a fraccion XXXVII Bis defines Participante Indirecto as a client of a participant passing transfers under a Contrato de Servicios de Participacion Indirecta, that Regla 2a fraccion XXXVI excludes Participantes Indirectos from the Participante definition, that Regla 2a fraccion XXII excludes their internal ledgers from Cuentas del SPEI, and that Reglas 9a Bis 1 to 9a Bis 10 and 86a set the regime and the compensation delegation the record describes." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "mx-spei:rule.aviso-de-falla-en-sesenta-segundos", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.compensacion-por-demora-al-cliente", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.compensacion-por-demora-entre-participantes", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.guias-de-homologacion-obligatorias", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.participacion-indirecta", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "mx-spei:role.participante-receptor", "id": "role.participante-receptor", "rail": "mx-spei", "class": "Role", "name": "Participante Receptor (receiving participant)", "summary": "The participant that receives an Orden de Transferencia Aceptada por SPEI. It must credit the beneficiary's Cuenta del Cliente within the deadline its class and the order type set, send the Confirmación de Abono, and return the payment on any of the ten grounds in Regla 23a, stating the cause from the catalogue in section 9 of the Manual. It decides whether to run extra validations above six thousand UDIS, whether to accept optional transfer order types at all, and whether to accept a support request under the Convenio. It pays the delay compensation, to its own customer or to the sending participant.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Reglas 2a, fracción XXXVIII, 19a, 20a, 23a, 24a, 25a, 28a, 30a and 86a", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 2a fracción XXXVIII, 19a, 20a, 23a to 25a, 28a, 30a and 86a, 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 from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 2a fraccion XXXVIII and Reglas 19a, 20a, 23a to 25a, 28a, 30a and 86a: the receiving participant must credit within its class's deadline, send the Confirmacion de Abono, return on the Regla 23a grounds stating the Manual's cause, choose on the six thousand UDIS validations, optional order types and support requests, and pay delay compensation." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "mx-spei:exc.devolucion-acreditada", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:exc.devolucion-acreditada", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:exc.devolucion-no-acreditada", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:exc.devolucion-no-acreditada", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:exc.solicitud-de-apoyo", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.aviso-de-falla-en-sesenta-segundos", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.calculo-de-la-compensacion-por-demora", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.canales-y-plazos-de-la-informacion", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.catalogo-de-causas-de-devolucion-no-publico", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.causas-de-devolucion-no-acreditada", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.compensacion-por-demora-al-cliente", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.compensacion-por-demora-entre-participantes", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.convenio-de-colaboracion-obligatorio", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.cuotas-del-spei", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.devolucion-acreditada-extemporanea", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.devolucion-de-transferencia-acreditada", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.devolucion-extemporanea-lleva-la-compensacion", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.el-convenio-puede-fijar-plazos-menores", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.el-receptor-puede-rechazar-tipos-opcionales", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.fondeo-de-las-cuentas-del-spei", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.informacion-de-la-transferencia-al-cliente", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.la-devolucion-vuelve-por-la-misma-instancia", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.limite-de-saldo-por-cliente", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.pagina-de-aclaraciones-y-reclamaciones", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.plazo-de-devolucion-no-acreditada", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.razon-de-la-no-acreditacion-y-canal-gratuito", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.reintento-de-una-devolucion-eliminada", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.sin-comisiones-por-enviar-recibir-devolver-o-abonar", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.sin-confirmacion-de-abono-no-hay-cep", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.ultimos-cinco-minutos-sin-compensacion", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.umbral-de-seis-mil-udis-validaciones-adicionales", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.vinculo-al-cep-en-cinco-minutos", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "mx-spei:rule.abono-de-la-devolucion-acreditada", "id": "rule.abono-de-la-devolucion-acreditada", "rail": "mx-spei", "class": "Rule", "name": "The sending participant credits its customer within thirty seconds of the credited return settling, four for CoDi", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 31a, first, second, third and fourth paragraphs and the last paragraph", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-emisor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "mx-spei:exc.devolucion-acreditada", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 31a, 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 from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 31a: the sending participant credits a credited return within thirty seconds of its settlement advice, four for CoDi, extends the window to an indirect customer, and where it cannot credit must not resend the money and must make it available at a counter or for transfer elsewhere." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.abono-de-la-devolucion-no-acreditada", "id": "rule.abono-de-la-devolucion-no-acreditada", "rail": "mx-spei", "class": "Rule", "name": "The sending participant credits its customer within five seconds of the return settling, four for CoDi", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 27a, first, second, third and fourth paragraphs", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-emisor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "mx-spei:exc.devolucion-no-acreditada", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 27a, 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 from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 27a: the sending participant credits a not credited or extemporanea return within five seconds of its settlement advice, four for CoDi, must ensure an indirect participant credits within the same window, and must not generate a further return where it cannot credit." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.ampliacion-o-suspension-del-horario", "id": "rule.ampliacion-o-suspension-del-horario", "rail": "mx-spei", "class": "Rule", "name": "The Administrador may extend or suspend the hours, and a participant may ask for up to sixty minutes", "statement": "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.", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Reglas 36a, 37a and 38a", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.banco-de-mexico", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 36a, 37a and 38a, 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 from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Reglas 36a to 38a: the Administrador may extend hours or suspend service for force majeure and must notify participants of an extension, a participant with a technical or operational problem may request an extension at least thirty minutes before close on the Apendice J form, and an extension runs one to four fifteen minute periods, sixty minutes at most, the first beginning one second after the scheduled close." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.autorizacion-admision-y-contrato", "id": "rule.autorizacion-admision-y-contrato", "rail": "mx-spei", "class": "Rule", "name": "Three gates before an institution can operate: an authorisation, an admission and a contract", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Reglas 4a, 56a, last paragraph, 57a, first paragraph, 62a, 64a and 65a", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.banco-de-mexico", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 4a, 56a, 57a, 62a, 64a and 65a, read 2026-09-20. Circular 13/2017 was not opened.", "confidence": "high" }, "currency": { "effective_since": "2022-03-23", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Reglas 4a, 56a, 57a, 62a, 64a and 65a: an applicant must meet the Reglas and Manual requirements, obtain Banco de Mexico authorisation under Circular 13/2017, be admitted by the Administrador and sign the Contrato, and that the admission request is signed by the chief executive or an officer no more than two levels below and comes with the Regla 62a compliance reports. Circular 13/2017 itself was not opened." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.aviso-de-falla-en-sesenta-segundos", "id": "rule.aviso-de-falla-en-sesenta-segundos", "rail": "mx-spei", "class": "Rule", "name": "A participant whose own infrastructure fails must tell affected customers within sixty seconds", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 89a, first and second paragraphs", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-emisor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-receptor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-indirecto", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 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 from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 89a first and second paragraphs: a participant whose own infrastructure or ordinary operation fails must tell affected customers within sixty seconds through the channels they use to instruct or try to instruct, unless the failure took out those channels, in which case notice goes once they are restored, and the same duty runs to indirect customers through the indirect participant." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.aviso-de-la-causa-al-cliente-emisor", "id": "rule.aviso-de-la-causa-al-cliente-emisor", "rail": "mx-spei", "class": "Rule", "name": "The paying customer must be told the money is back and why, within five seconds of the credit", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 27a, last paragraph", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-emisor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "mx-spei:exc.devolucion-no-acreditada", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 27a, 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 from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 27a last paragraph: the sending participant must tell the customer, free and within five seconds of crediting a return or extemporanea return, that the funds are back and the cause the receiving participant gave." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.calculo-de-la-compensacion-por-demora", "id": "rule.calculo-de-la-compensacion-por-demora", "rail": "mx-spei", "class": "Rule", "name": "The compensation is the greater of a floor in UMA and twice a formula over the delay in seconds", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 87a, and Regla 86a, the paragraphs on the greater of the two amounts", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-emisor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-receptor", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 86a and 87a, read 2026-09-20. No typed parameter holds an arithmetic expression, so the formula is in the statement.", "confidence": "high" }, "currency": { "effective_since": "2022-03-23", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 87a's three step formula (Tasa Ponderada de Fondeo Bancario times the transfer amount times seconds of delay, divided by 31,104,000) and Regla 86a's floor of the greater of 3.5 times the daily UMA or twice that reference amount, one daily UMA instead of 3.5 for CoDi." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.canales-y-plazos-de-la-informacion", "id": "rule.canales-y-plazos-de-la-informacion", "rail": "mx-spei", "class": "Rule", "name": "Monthly by post or in the statement, and in the electronic channels within sixty seconds for three months", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 84a, fracciones I, II and III", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-emisor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-receptor", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 84a, 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 from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 84a fracciones I to III: free information within fifteen calendar days by post unless already in the statement, and in internet and mobile channels within sixty seconds of the settlement advice, kept at least three months, with automated teller machine requests excepted." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.cancelacion-solo-antes-de-la-liquidacion", "id": "rule.cancelacion-solo-antes-de-la-liquidacion", "rail": "mx-spei", "class": "Rule", "name": "A sent order can be cancelled only while it is unsettled, and there is no recall after that", "statement": "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.", "rests_on": "rule", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 17a, third paragraph, and Regla 18a", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-emisor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mx-spei:rule.firmeza-e-irrevocabilidad-legal", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 17a and 18a, 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 from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 17a third paragraph lets the sending participant cancel only while the order is unsettled under Regla 18a, and that after settlement the order is an Orden de Transferencia Aceptada por SPEI." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.catalogo-de-causas-de-devolucion-no-publico", "id": "rule.catalogo-de-causas-de-devolucion-no-publico", "rail": "mx-spei", "class": "Rule", "name": "The numbered catalogue of return causes is in the Manual and is not public", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Reglas 24a, 23a, fracción VIII, 2a, fracción XXX, and 57a, second paragraph", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-receptor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "mx-spei:exc.devolucion-no-acreditada", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mx-spei:rule.contrato-unilateral-de-confidencialidad", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mx-spei:rule.formatos-y-tipos-en-el-manual", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 24a, 23a fracción VIII, 2a fracción XXX and 57a, read 2026-09-20. The catalogue itself was not consulted and is not to be sought through third parties, mirrors or document sharing sites.", "confidence": "high" }, "currency": { "effective_since": "2022-03-23", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 24a requires the cause to be stated from the catalogue in section 9 of the Manual, Regla 23a fraccion VIII makes that catalogue strictly longer than the ten named grounds, Regla 2a fraccion XXX defines the Manual as prepared by the Administrador and made available to Participantes, and Regla 57a requires the confidentiality undertaking before an applicant may even file for admission." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "mx-spei:rule.formatos-y-tipos-en-el-manual", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "mx-spei:rule.causas-de-devolucion-no-acreditada", "id": "rule.causas-de-devolucion-no-acreditada", "rail": "mx-spei", "class": "Rule", "name": "Ten grounds on which the receiving participant must return a payment it could not credit", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 23a, fracciones I to X", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-receptor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "mx-spei:exc.devolucion-no-acreditada", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 23a, 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 from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 23a fracciones I to X state the ten grounds in the order and substance the record gives." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.clave-de-rastreo-y-referencia-numerica", "id": "rule.clave-de-rastreo-y-referencia-numerica", "rail": "mx-spei", "class": "Rule", "name": "The two identifiers a customer can see and quote", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Reglas 2a, fracciones IX and XL, 14a, 17a, 23a, fracción X, and 83a, fracción I, incisos f) and g)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-emisor", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 2a fracciones IX and XL, 14a, 17a, 23a fracción X and 83a, read 2026-09-20. The permitted lengths of both fields are set in section 8 of the Manual and are not public.", "confidence": "high" }, "currency": { "effective_since": "2022-03-23", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 2a fracciones IX and XL define the Clave de Rastreo as alphanumeric data the sending participant assigns per Regla 14a and the Referencia Numerica as numeric data the customer supplies, that Regla 83a makes both shown back to the customer, that Regla 17a requires a new Clave de Rastreo on a resubmitted request, and that Regla 23a fraccion X makes a repeated Clave de Rastreo on the same operation date a mandatory return ground." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.compensacion-por-demora-al-cliente", "id": "rule.compensacion-por-demora-al-cliente", "rail": "mx-spei", "class": "Rule", "name": "A participant that misses a sending, crediting or return crediting deadline pays its own customer", "statement": "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.", "rests_on": "rule", "facet": "liability", "parameters": { "liability_holder": { "role": "mx-spei:role.participante-emisor", "condition": "missed the sending deadline in Regla 17a or a return crediting deadline in Reglas 27a or 31a", "text": "The sending participant pays its own paying customer; separately the receiving participant pays its beneficiary customer for missing Regla 19a. One record can name only one holder, so the receiving participant's case is in the statement." } }, "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 86a, fracciones I, I Bis and II", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-emisor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-receptor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-indirecto", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 86a, 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 from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 86a fracciones I, I Bis and II: the sending participant pays its own customer for missing the Regla 17a sending deadline or the Regla 27a or 31a return crediting deadlines, and the receiving participant pays its beneficiary for missing the Regla 19a crediting deadline, both by the close of the next SPEI operating day, with the indirect participant chain verified under the Contrato de Servicios de Participacion Indirecta." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.compensacion-por-demora-entre-participantes", "id": "rule.compensacion-por-demora-entre-participantes", "rail": "mx-spei", "class": "Rule", "name": "A receiving participant that returns late pays the sending participant, inside the return itself", "statement": "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.", "rests_on": "rule", "facet": "liability", "parameters": { "liability_holder": { "role": "mx-spei:role.participante-receptor", "condition": "missed a return deadline in Regla 25a or Regla 30a", "text": "The receiving participant pays the sending participant by adding the Regla 87a amount to the extemporánea return." } }, "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 86a, fracciones III and III Bis", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-receptor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-emisor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-indirecto", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 86a, 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 from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 86a fracciones III and III Bis: a receiving participant that misses a Regla 25a or 30a return deadline pays the sending participant by adding the Regla 87a amount to the extemporanea return itself, including where the party in default is a beneficiary customer acting as an indirect participant." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.conexion-a-las-instancias-del-spei", "id": "rule.conexion-a-las-instancias-del-spei", "rail": "mx-spei", "class": "Rule", "name": "Which instances a participant must connect to depends on its class and its account count", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 5a Bis, fracciones I and II and the paragraphs that follow", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 5a Bis, read 2026-09-20. Which order sets sit on which instance is in section 9 of the Manual and is not public.", "confidence": "high" }, "currency": { "effective_since": "2022-03-23", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 5a Bis: a credit institution or electronic payment funds institution with at least three thousand accounts, or any participant that has opted in under Apendice G, must connect to every instance every operating day; others connect only to their assigned instance but must be able to connect elsewhere on the Administrador's instruction, and every participant needs certified Aplicativos SPEI." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.consulta-de-cep-por-lotes", "id": "rule.consulta-de-cep-por-lotes", "rail": "mx-spei", "class": "Rule", "name": "The public batch lookup for payment receipts, and the shape of its input file", "statement": "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.", "rests_on": "guidance", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.cep-scl-guia", "section": "sections 2, 3.1 and 4.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Guía de Operación para Usuarios del CEP-Servicio de Consulta por Lotes, November 2025, sections 2, 3.1 and 4.3, read in full on 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2018-03-16", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form. The date is the earliest transfer date for which the service can produce a receipt, which the guide states. The guide's own edition is November 2025.", "source_edition": "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", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "mx-spei:src.cep-scl-guia", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms sections 2 and 3.1: the batch service generates two to five hundred CEP as PDF, XML or both in a ZIP, for transfers between different participants made from 2018-03-16, from a UTF-8 no BOM text file with one comma separated line per transfer (date, Clave de Rastreo, sending and receiving institution keys, beneficiary account, amount), and section 4.3 confirms the resumen.txt output and the three reasons a CEP cannot be produced." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.contrato-unilateral-de-confidencialidad", "id": "rule.contrato-unilateral-de-confidencialidad", "rail": "mx-spei", "class": "Rule", "name": "Before it may even apply, an institution must sign a confidentiality undertaking over all SPEI information", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 57a, second paragraph", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 57a, 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 from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 57a second paragraph requires an applicant, before filing its admission request, to sign a unilateral confidentiality contract on the Administrador's clauses covering all SPEI information in any form, to use it only for the Reglas' purposes, to limit access, to answer for its own people's use of it, and to hold the Administrador harmless." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "mx-spei:rule.catalogo-de-causas-de-devolucion-no-publico", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "mx-spei:rule.convenio-de-colaboracion-obligatorio", "id": "rule.convenio-de-colaboracion-obligatorio", "rail": "mx-spei", "class": "Rule", "name": "Participants must enter into a fraud collaboration agreement, and Regla 43a sets what it must contain", "statement": "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.", "rests_on": "rule", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 43a, fracciones I to VIII", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-emisor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-receptor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "mx-spei:exc.solicitud-de-apoyo", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 43a, read 2026-09-20. The Convenio's own text is not public and was not consulted.", "confidence": "high" }, "currency": { "effective_since": "2025-02-21", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 2/2025, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 43a fracciones I to VIII list the required contents of the Convenio de Colaboracion para la Proteccion de Clientes Emisores, including the support request procedure, evidence keeping, acceptance criteria and times, beneficiary restriction mechanics subject to CNBV rules, release and return mechanisms, the fraud presumption trigger, and dispute handling, and that a participant operating an international foreign exchange settlement system including the peso need not join." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.criterios-para-ser-participante", "id": "rule.criterios-para-ser-participante", "rail": "mx-spei", "class": "Rule", "name": "Four categories of institution may act as a participant", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Reglas 56a, fracciones I to IV, 32a and 33a", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 56a, 32a and 33a, 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 from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 14/2017, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 56a fracciones I to IV list the four participant categories and that Reglas 32a and 33a let credit institution participants send and receive CLS orders through Banco de Mexico." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.cuotas-del-spei", "id": "rule.cuotas-del-spei", "rail": "mx-spei", "class": "Rule", "name": "A fixed monthly quota plus a per operation quota, with CoDi returns exempt", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 90a, first and second paragraphs", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-emisor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-receptor", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 90a, read 2026-09-20. The tariff figures are told to participants individually and are not public.", "confidence": "high" }, "currency": { "effective_since": "2022-03-23", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 90a first and second paragraphs: a fixed monthly quota due the tenth banking day of the following month covering unlimited sending and receiving, plus a per operation quota on transfer requests, not credited returns whether extemporanea or not, CLS orders and retransmitted bytes, with CoDi returns exempt, and tariffs told to participants by the last banking day of November." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.datos-a-confirmar-antes-de-autorizar", "id": "rule.datos-a-confirmar-antes-de-autorizar", "rail": "mx-spei", "class": "Rule", "name": "A confirmation screen must show five things before the customer authorises", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.guias-homologacion", "section": "section V.C, numerals 1 and 2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-emisor", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Guías versión 1.1 section V.C, read 2026-09-20.", "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, which added the Guías to the Reglas and made them binding. Participants and the indirect participants they contract with have until 2026-12-14 to comply, under the second transitorio of that circular, and version 1.1 of the Guías itself takes effect on the same date. So the obligation exists now and the interface it requires is due by 2026-12-14.", "source_edition": "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": "mx-spei:src.guias-homologacion", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms section V.C (tercera etapa) numerals 1 and 2: the confirmation screen must show at least the amount, beneficiary name, beneficiary account, receiving participant and source account, and the customer must actively accept before the entity proceeds to its own authorisation and authentication, which may add further checks." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.datos-en-la-notificacion-del-resultado", "id": "rule.datos-en-la-notificacion-del-resultado", "rail": "mx-spei", "class": "Rule", "name": "The result screen must carry the status, the Clave de Rastreo and a link to the CEP", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.guias-homologacion", "section": "section V.D, numerals 1 to 3, and section V.E, numeral 6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-emisor", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Guías versión 1.1 sections V.D and V.E, read 2026-09-20. The Guías require a clear rejection message but do not supply any wording or code for one.", "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, which added the Guías to the Reglas and made them binding. Participants and the indirect participants they contract with have until 2026-12-14 to comply, under the second transitorio of that circular, and version 1.1 of the Guías itself takes effect on the same date. So the obligation exists now and the interface it requires is due by 2026-12-14.", "source_edition": "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": "mx-spei:src.guias-homologacion", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms section V.D (cuarta etapa) numerals 1 to 3: the result screen shows the operation status, amount, concept, reference and masked beneficiary details, plus Clave de Rastreo and a CEP download link for inter-institution operations or a folio for intra-institution ones, and section V.E numeral 6 requires error, rejection and cancellation messages to be precise and clear." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.devolucion-acreditada-extemporanea", "id": "rule.devolucion-acreditada-extemporanea", "rail": "mx-spei", "class": "Rule", "name": "A credited return sent on a later operating day is the extemporánea type", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 29a, and Regla 86a, fracción III", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-receptor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "mx-spei:exc.devolucion-acreditada", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "mx-spei:txn.devolucion", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 29a and 86a fracción III, 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 from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 29a makes a credited return sent on a later operating day the devolucion extemporanea type, and Regla 86a fraccion III adds the Regla 87a compensation to the amount." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.devolucion-de-transferencia-acreditada", "id": "rule.devolucion-de-transferencia-acreditada", "rail": "mx-spei", "class": "Rule", "name": "A beneficiary who does not recognise a credited payment may instruct its return, within thirty seconds", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Reglas 28a and 30a, first and third paragraphs", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-receptor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.cliente-beneficiario", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "mx-spei:exc.devolucion-acreditada", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 28a and 30a, 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 from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Reglas 28a and 30a: a beneficiary who does not recognise a credited payment may present a Solicitud de Envio for a credited return, sent within thirty seconds, four for CoDi, and that the participant must also send one on its own where the Convenio says the funds must return or where it failed to send the CoDi credit advice, at eight seconds from the settlement advice." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.devolucion-extemporanea-lleva-la-compensacion", "id": "rule.devolucion-extemporanea-lleva-la-compensacion", "rail": "mx-spei", "class": "Rule", "name": "A late return becomes the extemporánea type and its amount must include the delay compensation", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Reglas 26a and 24a, fracción II", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-receptor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "mx-spei:exc.devolucion-no-acreditada", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "mx-spei:txn.devolucion", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 26a and 24a fracción II, read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2019-05-20", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 8/2019, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 26a makes a not credited return sent on a later operating day the devolucion extemporanea type in the section 8 format, with the amount the original plus the Regla 87a compensation under Regla 24a fraccion II." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.dia-de-operacion-del-spei", "id": "rule.dia-de-operacion-del-spei", "rail": "mx-spei", "class": "Rule", "name": "Continuous operation, and an operating day that starts at 18:00:00 the previous banking day", "statement": "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.", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 35a", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.banco-de-mexico", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 35a, read 2026-09-20. The window is in the statement and not typed: the operating day opens at 18:00:00 on one banking day and closes at 17:59:59 on the next, so its two times do not run forward within one day and the schema's deadline shape refuses them.", "confidence": "high" }, "currency": { "effective_since": "2022-03-23", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 35a: continuous operating scheme, and the operating day for a banking day runs from 18:00:00 the previous banking day to 17:59:59 that banking day, in every instance." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.el-administrador-queda-liberado", "id": "rule.el-administrador-queda-liberado", "rail": "mx-spei", "class": "Rule", "name": "The Administrador is released from liability for what it does under the Reglas and the Manual", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 22a", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.banco-de-mexico", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 22a, 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 from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 14/2017, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 22a releases the Administrador from liability to participants and customers for SPEI actions the Reglas provide for and that follow the Manual, automated ones included." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.el-convenio-puede-fijar-plazos-menores", "id": "rule.el-convenio-puede-fijar-plazos-menores", "rail": "mx-spei", "class": "Rule", "name": "Where the Convenio sets shorter return deadlines than the Reglas, the Convenio's deadlines govern", "statement": "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.", "rests_on": "rule", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 30a, last paragraph", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-receptor", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 30a, 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 from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 30a last paragraph lets the Convenio de Colaboracion set shorter credited return deadlines than the Regla's own thirty, four and eight second figures, which then govern." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.el-emisor-verifica-y-decide-aceptar-la-solicitud", "id": "rule.el-emisor-verifica-y-decide-aceptar-la-solicitud", "rail": "mx-spei", "class": "Rule", "name": "The sending participant decides whether to accept the customer's request at all", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 7a, fracción II, and Regla 13a", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-emisor", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 7a and 13a, read 2026-09-20. The acceptance criteria are the participant's own.", "confidence": "medium" }, "currency": { "effective_since": "2022-03-23", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 7a fraccion II: the sending participant runs the Regla 13a checks and decides whether to accept the Solicitud de Envio, processing it by sending the order if accepted or rejecting it and telling the customer the cause if not." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.el-receptor-puede-rechazar-tipos-opcionales", "id": "rule.el-receptor-puede-rechazar-tipos-opcionales", "rail": "mx-spei", "class": "Rule", "name": "A receiving participant may tell the Administrador it will not take certain order types", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 23a, fracción V, Regla 19a, fracción I, and Regla 43a, fracción III", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-receptor", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 23a fracción V, 19a fracción I and 43a fracción III, read 2026-09-20. The optional type list is in section 9 of the Manual and is not public.", "confidence": "medium" }, "currency": { "effective_since": "2022-03-23", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 23a fraccion V makes an order of a type the Manual's section 9 marks optional, that the receiving participant told the Administrador it would not take, a mandatory return ground, and that Reglas 19a fraccion I and 43a fraccion III give the same participant the six thousand UDIS validation choice and the support request decision." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.eliminacion-de-ordenes-no-liquidadas", "id": "rule.eliminacion-de-ordenes-no-liquidadas", "rail": "mx-spei", "class": "Rule", "name": "Four grounds on which the Administrador eliminates an order it has not settled", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 17a, fracciones I to IV, and the paragraph added by Circular 1/2022", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.banco-de-mexico", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "mx-spei:exc.eliminacion", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 17a, 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 from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 17a fracciones I to IV and the following paragraphs: the Administrador eliminates an order unsettled at close, a non-CoDi order unsettled after the clearing cycles section 5.7 of the Manual sets because of a short Cuenta del SPEI or a disconnected receiver, a CoDi order unsettled after the next clearing cycle, or an order it cannot process, and may also eliminate an order while the sender's balance is short." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.firmeza-e-irrevocabilidad-legal", "id": "rule.firmeza-e-irrevocabilidad-legal", "rail": "mx-spei", "class": "Rule", "name": "Accepted orders, their netting and their settlement are firm, irrevocable, enforceable and effective against third parties", "statement": "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.", "rests_on": "law", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.ley-sistemas-de-pagos", "section": "article 11, first and third paragraphs, and article 2, fracción II", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Ley de Sistemas de Pagos articles 2 and 11, read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2002-12-12", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form. The date is the day the Ley de Sistemas de Pagos was published in the Diario Oficial de la Federación. The law was last reformed on 2025-11-14, and that reform changed articles 9, 12 and 33, not article 11.", "source_edition": "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": "mx-spei:src.ley-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 four part standard of firm, irrevocable, enforceable and effective against third parties, that compensacion in article 2 fraccion II is netting rather than the Reglas delay payment, and that creditors and insolvency bodies keep their general law claims for damages without being able to unwind settlement." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "mx-spei:rule.cancelacion-solo-antes-de-la-liquidacion", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "mx-spei:rule.fondeo-de-las-cuentas-del-spei", "id": "rule.fondeo-de-las-cuentas-del-spei", "rail": "mx-spei", "class": "Rule", "name": "A Cuenta del SPEI is funded from SIAC-BANXICO or DALÍ, or by incoming credits, and swept at close", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 6a, second, third and fourth paragraphs", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-emisor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-receptor", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 6a, 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 from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 6a second to fourth paragraphs: a Cuenta del SPEI other than the Cuenta Alterna is funded from SIAC-BANXICO, DALI or incoming credits, a credit institution's balance sweeps to its Cuenta Unica at close, and a non-credit-institution's balance is held overnight in a SIAC-BANXICO concentrating account without interest and credited back at the section 3 time on the next operating day." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.formatos-y-tipos-en-el-manual", "id": "rule.formatos-y-tipos-en-el-manual", "rail": "mx-spei", "class": "Rule", "name": "Every transfer order type, every message format and the CLABE structure are in the Manual, and it is not public", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Reglas 5a, 2a, fracciones VIII and XXX, 24a, 20a and 21a", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "mx-spei:rule.catalogo-de-causas-de-devolucion-no-publico", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 5a, 2a fracciones VIII and XXX, 20a, 21a and 24a, read 2026-09-20. That no ISO 20022 message name appears is an absence found by reading the compiled text, 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 from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 5a points transfer order types to section 8 of the Manual and instances to section 9, Regla 2a fraccion VIII points the CLABE structure to section 6, Regla 2a fraccion XXX defines the Manual as participant directed, and Reglas 20a, 21a and 24a keep the confirmation and return formats in section 8. Confirms no ISO 20022 message name appears anywhere in the 296 page compiled text, stated as an absence." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "mx-spei:rule.catalogo-de-causas-de-devolucion-no-publico", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "mx-spei:rule.guias-de-homologacion-obligatorias", "id": "rule.guias-de-homologacion-obligatorias", "rail": "mx-spei", "class": "Rule", "name": "The Guías are part of the SPEI rules and the mobile interface must follow them", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Reglas 2a, fracción XXVII Quáter, 7a, 9a Bis 10, fracción I, 10a and 71a, fracción V", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "mx-spei:src.guias-homologacion", "section": "section II, alcance, and section VII, control de versiones", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-emisor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-indirecto", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.banco-de-mexico", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 2a fracción XXVII Quáter, 7a, 9a Bis 10, 10a and 71a; Guías versión 1.1 sections II and VII; read 2026-09-20. Chief of Staff decision of 2026-09-20: the Guías are a RuleSource that the consumer-law and messages facts cite for their substantive lines, not a facet of their own.", "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, which added the Guías to the Reglas and made them binding. Participants and the indirect participants they contract with have until 2026-12-14 to comply, under the second transitorio of that circular, and version 1.1 of the Guías itself takes effect on the same date. So the obligation exists now and the interface it requires 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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 2a fraccion XXVII Quater defines the Guias, and Reglas 7a, 9a Bis 10 fraccion I, 10a and 71a fraccion V bind their user experience specifications on the ordinary process, indirect instruction forms, mobile Solicitudes de Envio and non-credit-institution electronic channels respectively; also confirms Regla 7a's added paragraph requiring the Administrador to publish and date each version and keep earlier ones posted. Circular 9/2026 itself, fetched and read separately, confirms the DOF date 2026-06-17 and the second transitorio's 2026-12-14 compliance deadline." }, { "source": "mx-spei:src.guias-homologacion", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms section II states the Guias' specifications were established by Circular 9/2026 amending the Reglas del SPEI and by Circular 10/2026 amending Circular 3/2012, and section VII's version control table dates version 1.1 to publication 2026-08-28 and entry into force 2026-12-14. Circular 10/2026 itself was not opened." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.horarios-en-hora-de-la-ciudad-de-mexico", "id": "rule.horarios-en-hora-de-la-ciudad-de-mexico", "rail": "mx-spei", "class": "Rule", "name": "Every time in the Reglas is Mexico City time unless it says otherwise", "statement": "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.", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 34a", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 34a, 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 from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 14/2017, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 34a: unless stated otherwise, every time the Reglas and other applicable provisions give is referred to the Mexico City time zone." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.informacion-de-la-transferencia-al-cliente", "id": "rule.informacion-de-la-transferencia-al-cliente", "rail": "mx-spei", "class": "Rule", "name": "What each side must tell its own customer about a settled transfer", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 83a, fracciones I to IV", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-emisor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-receptor", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 83a, read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2025-02-21", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 2/2025, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 83a fracciones I to IV: the sending participant's disclosure to its paying customer (receiving participant name, settlement date and time to the second, amount, beneficiary identifier, unverified beneficiary name phrase, Clave de Rastreo, Referencia Numerica, concept, CoDi folio) and the receiving participant's disclosure to its beneficiary, including the CoDi labelling requirement and the mobile number masking rule." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.la-devolucion-vuelve-por-la-misma-instancia", "id": "rule.la-devolucion-vuelve-por-la-misma-instancia", "rail": "mx-spei", "class": "Rule", "name": "A return goes back through the instance the original came in on", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Reglas 24a, 26a, second paragraph, 30a, second paragraph, and 2a, fracción XXVIII Bis", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-receptor", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 24a, 26a, 30a and 2a fracción XXVIII Bis, read 2026-09-20. Which order types sit on which instance is in section 9 of the Manual and is not public.", "confidence": "high" }, "currency": { "effective_since": "2022-03-23", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 2a fraccion XXVIII Bis defines Instancia del SPEI as a processing component assigned by section 9 of the Manual, and Reglas 24a, 26a and 30a require a not credited or extemporanea return to go back through the instance the original used, except in the section 5.16.4 cases." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.limite-de-saldo-por-cliente", "id": "rule.limite-de-saldo-por-cliente", "rail": "mx-spei", "class": "Rule", "name": "A non-bank participant that may not hold customer balances must sweep a customer out at a computed limit", "statement": "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.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 70a, fracciones I and II, and Regla 23a, fracción VII", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-receptor", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 70a and 23a fracción VII, read 2026-09-20. The limit is a computed figure, not a stated amount, so it cannot be typed.", "confidence": "high" }, "currency": { "effective_since": "2022-03-23", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 70a fracciones I and II: a non-bank participant that may not hold customer balances must sweep a customer's balance out within two minutes of passing a limit computed as its Regla 68a protection resources divided by its paying customer count, reported quarterly, and Regla 23a fraccion VII makes an incoming transfer with no pre-agreed sweep account a mandatory return ground." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.liquidacion-casi-en-tiempo-real", "id": "rule.liquidacion-casi-en-tiempo-real", "rail": "mx-spei", "class": "Rule", "name": "A hybrid design that settled a payment in 1.9 seconds on average as at 2016", "statement": "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.", "rests_on": "guidance", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.spei-pfmi", "section": "executive summary, and section III on the general system design", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "SPEI PFMI disclosure of 2016-03-28, executive summary and general system design, read 2026-09-20. The document is ten years old and predates six of the eleven amending circulares, so it is read for the settlement model only.", "confidence": "medium" }, "currency": { "effective_since": "2016-03-28", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form. The date is the disclosure date the document carries. It is not the date a rule took effect; it is the date on which Banco de México described the system this way, and nothing public has restated it since [Unverified].", "source_edition": "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": "mx-spei:src.spei-pfmi", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms the executive summary and section III general design: SPEI is a hybrid system settling practically in real time, averaging 1.9 seconds with results posted immediately, high priority orders tried first with access to reserved balance, orders may be bundled into one instruction, and the V and T send topologies as the record describes them, all as at the 2016-03-28 disclosure date, before the SPEI instances existed." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.liquidacion-contra-el-saldo-de-la-instancia", "id": "rule.liquidacion-contra-el-saldo-de-la-instancia", "rail": "mx-spei", "class": "Rule", "name": "The Administrador validates, then settles against the instance account, taking pending orders and priority into account", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 18a, first paragraph", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.banco-de-mexico", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 18a, read 2026-09-20. The mechanics inside section 4 of the Manual are not public.", "confidence": "high" }, "currency": { "effective_since": "2022-03-23", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 18a first paragraph: after automated validation the Administrador settles through the section 4 Manual process, weighing the instance account balance, pending orders and the order's priority." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.medidas-judiciales-desde-el-dia-siguiente", "id": "rule.medidas-judiciales-desde-el-dia-siguiente", "rail": "mx-spei", "class": "Rule", "name": "A court, regulator or insolvency measure bites only from the banking day after it is served on the Administrador", "statement": "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.", "rests_on": "law", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.ley-sistemas-de-pagos", "section": "article 11, second paragraph, and article 13", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Ley de Sistemas de Pagos articles 11 and 13, read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2002-12-12", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form. The date is the day the Ley de Sistemas de Pagos was published in the Diario Oficial de la Federación.", "source_edition": "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": "mx-spei:src.ley-sistemas-de-pagos", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms article 11 second paragraph holds judicial, administrative and insolvency measures against a participant off until the banking day after they are served on the Administrador in the manner article 13 sets, so payments already in flight on the day of service are not caught." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.nombre-del-participante-receptor-desde-el-identificador", "id": "rule.nombre-del-participante-receptor-desde-el-identificador", "rail": "mx-spei", "class": "Rule", "name": "The screen must show the receiving participant derived from the account identifier", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.guias-homologacion", "section": "section V.B, momento 2, numerals 3 and 4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-emisor", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Guías versión 1.1 section V.B, read 2026-09-20. The CLABE structure that makes the derivation possible is in section 6 of the Manual and is not public.", "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, which added the Guías to the Reglas and made them binding. Participants and the indirect participants they contract with have until 2026-12-14 to comply, under the second transitorio of that circular, and version 1.1 of the Guías itself takes effect on the same date. So the obligation exists now and the interface it requires is due by 2026-12-14.", "source_edition": "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": "mx-spei:src.guias-homologacion", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms section V.B, momento 2, numerals 3 and 4: the interface must let the customer capture the beneficiary by identifier, contacts or QR, and must show the SPEI participant tied to the identifier, deriving it from a CLABE without asking, showing the indirect participation provider where applicable, letting the customer correct it for other identifiers except where a mobile number's receiving participant came from the Administrador." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.noventa-y-cuatro-participantes-directos", "id": "rule.noventa-y-cuatro-participantes-directos", "rail": "mx-spei", "class": "Rule", "name": "94 direct participants at 2026-09-10, in eleven categories", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.participantes-directos", "section": "listado público updated 2026-09-10, all eleven category headings", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Participantes directos en el SPEI, listado público updated 2026-09-10, read in full on 2026-09-20. The count and every category figure are printed in the document.", "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 list, which the document prints on its first page. The list changes without notice, so this line is a snapshot.", "source_edition": "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": "mx-spei:src.participantes-directos", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms the list dated 2026-09-10 carries 94 participants in the eleven categories and counts the record states: 46 banca multiple, 6 banca de desarrollo, 13 instituciones de fondos de pago electronico, 9 casas de bolsa, 8 sociedades financieras populares, 4 transmisores de dinero, 4 sociedades cooperativas de ahorro y prestamo, 1 camara de compensacion, 1 afore, 1 fondo y fideicomiso and 1 deposito de valores." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.orden-aceptada-por-spei", "id": "rule.orden-aceptada-por-spei", "rail": "mx-spei", "class": "Rule", "name": "An order becomes an Orden de Transferencia Aceptada por SPEI when it is settled and advised", "statement": "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.", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 18a, second and third paragraphs", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.banco-de-mexico", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 18a, 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 from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 18a second and third paragraphs: an order becomes an Orden de Transferencia Aceptada por SPEI once validated, settled and the Aviso de Liquidacion is available to both participants, and that these are the accepted transfer orders the Ley de Sistemas de Pagos refers to." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.pagina-de-aclaraciones-y-reclamaciones", "id": "rule.pagina-de-aclaraciones-y-reclamaciones", "rail": "mx-spei", "class": "Rule", "name": "Every participant must publish how to file a clarification, a status enquiry or a claim", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 84a, fracciones VI and VII", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-emisor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-receptor", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 84a, 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 from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 84a fracciones VI and VII: a published page linked from electronic channels other than automated teller machines describing the clarification, status enquiry and claim procedure, and a section for a customer to check CoDi order status for at least the last three months." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.participacion-indirecta", "id": "rule.participacion-indirecta", "rail": "mx-spei", "class": "Rule", "name": "Indirect participation is a defined regime, and the contract pushes the Reglas down a level", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Reglas 9a Bis 1 to 9a Bis 10, and Regla 86a, fracciones I Bis and III Bis", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-indirecto", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 9a Bis 1 to 9a Bis 10 and 86a, read 2026-09-20. The individual contracts are private.", "confidence": "high" }, "currency": { "effective_since": "2022-03-23", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Reglas 9a Bis 1 to 9a Bis 10 set the indirect participation regime (who may be served, exclusions, contract minimum contents, identification and validation duties, quarterly reports, suspension and termination) and that Regla 86a fracciones I Bis and III Bis make the participant verify the indirect participant pays the delay compensation." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.plazo-de-devolucion-no-acreditada", "id": "rule.plazo-de-devolucion-no-acreditada", "rail": "mx-spei", "class": "Rule", "name": "Sixty seconds from the settlement advice, with six named exceptions in seconds and clock times", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 25a, first paragraph and fracciones I to VII", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-receptor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "mx-spei:exc.devolucion-no-acreditada", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 25a, read 2026-09-20. The windows are stated in the text rather than as a typed time_window because the schema's smallest unit is an hour.", "confidence": "high" }, "currency": { "effective_since": "2025-02-21", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 2/2025, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.razon-de-la-no-acreditacion-y-canal-gratuito", "id": "rule.razon-de-la-no-acreditacion-y-canal-gratuito", "rail": "mx-spei", "class": "Rule", "name": "A beneficiary must be able to find out, free, why a settled payment was not credited", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 84a, fracciones IV and V", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-receptor", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 84a, read 2026-09-20. What the beneficiary is actually shown as the reason rests on the catalogue in section 9 of the Manual, which is not public.", "confidence": "high" }, "currency": { "effective_since": "2022-03-23", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 84a fracciones IV and V: where an order was not credited the receiving participant must make the Regla 83a information reachable by the beneficiary and must run a free channel answering why settled orders were not credited." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.reintento-de-una-devolucion-eliminada", "id": "rule.reintento-de-una-devolucion-eliminada", "rail": "mx-spei", "class": "Rule", "name": "A return that was eliminated without settling must be sent again, on one of two clocks", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 25a Bis, fracciones I and II", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-receptor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "mx-spei:exc.devolucion-no-acreditada", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mx-spei:exc.eliminacion", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 25a Bis, 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 from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 25a Bis fracciones I and II: a return eliminated without settling must be resent within five seconds of a reconnection notice or, absent one, within sixty minutes of the elimination notice, without changing instance, where the ground was the receiver's disconnection, and within five seconds of the elimination notice where the ground was the sender's own short balance." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.sin-comisiones-por-enviar-recibir-devolver-o-abonar", "id": "rule.sin-comisiones-por-enviar-recibir-devolver-o-abonar", "rail": "mx-spei", "class": "Rule", "name": "No fees between participants, none to a beneficiary, and none on CoDi or an eliminated order", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 88a", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-emisor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-receptor", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 88a, read 2026-09-20. The last paragraph's treatment of CoDi retries reads two ways and the record states the ambiguity rather than choosing.", "confidence": "high" }, "currency": { "effective_since": "2022-03-23", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 88a bars fees between participants for sending, receiving, returning or crediting, bars any fee to a beneficiary, bars sending-participant fees on CoDi orders and Mensaje de Cobro handling, bars receiving-participant fees on generating and sending Mensajes de Cobro, bars a fee on an eliminated order, and allows a retry fee only on success. Confirms the last paragraph names orders other than the return type and then names CoDi orders in a way that reads two ways, matching the record's stated ambiguity rather than a chosen answer." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.sin-confirmacion-de-abono-no-hay-cep", "id": "rule.sin-confirmacion-de-abono-no-hay-cep", "rail": "mx-spei", "class": "Rule", "name": "No receipt exists until the receiving participant confirms the credit", "statement": "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.", "rests_on": "guidance", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.cep-scl-guia", "section": "section 4.3, the resumen.txt outcomes", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Reglas 20a and 21a", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-receptor", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Guía de Operación para Usuarios del CEP-Servicio de Consulta por Lotes, November 2025, section 4.3; Reglas del SPEI 20a and 21a; read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2019-05-20", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 8/2019, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified]. The lines from the CEP batch guide carry that guide's own edition of November 2025.", "source_edition": "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; 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": "mx-spei:src.cep-scl-guia", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms section 4.3's resumen.txt lists the first cause a CEP cannot be produced as the receiving institution not yet having sent the Confirmacion de Abono, the second as a data mismatch with the Clave de Rastreo, and the third as a payment status other than Liquidado." }, { "source": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 20a requires the receiving participant to generate and send the Confirmacion de Abono after crediting, and Regla 21a lets the Administrador reject a non-conforming confirmation and gives the participant twenty four hours to correct and resend it." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.sin-sobregiros-en-la-cuenta-del-spei", "id": "rule.sin-sobregiros-en-la-cuenta-del-spei", "rail": "mx-spei", "class": "Rule", "name": "No participant may overdraw its Cuenta del SPEI", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 6a, first paragraph", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "mx-spei:src.spei-pfmi", "section": "executive summary and section III.C", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-emisor", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 6a; SPEI PFMI disclosure of 2016-03-28, executive summary and general system design; 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 from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified]. The PFMI lines carry the disclosure's own date of 2016-03-28.", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 6a first paragraph: a participant's Cuenta del SPEI balance is what settles its orders through that instance, and an order for more than that balance cannot settle, so no participant can overdraw." }, { "source": "mx-spei:src.spei-pfmi", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms the PFMI disclosure states SPEI grants no credit and permits no overdraft on participants' accounts, which are denominated in moneda nacional." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.suspension-de-solicitudes-durante-una-falla", "id": "rule.suspension-de-solicitudes-durante-una-falla", "rail": "mx-spei", "class": "Rule", "name": "A participant that cannot operate normally must stop taking send requests", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 89a, third paragraph", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-emisor", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 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 from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 89a third paragraph: a participant unable to operate normally must stop letting customers present Solicitudes de Envio, CoDi included, except the scheduled requests Regla 10a second and third paragraphs and Regla 14a fraccion III allow." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.ultimos-cinco-minutos-sin-compensacion", "id": "rule.ultimos-cinco-minutos-sin-compensacion", "rail": "mx-spei", "class": "Rule", "name": "Orders arriving in the last five minutes of the day may be returned in the first five of the next, free", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 86a, the paragraph added by Circular 8/2019", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-receptor", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 86a, read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2019-05-20", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 8/2019, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms the paragraph Circular 8/2019 added to Regla 86a: orders received in the five minutes before close that need returning under Regla 23a or 30a may be returned in the first five minutes of the next operating day with no Regla 87a compensation owed." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.umbral-de-bajo-valor-mil-quinientas-udis", "id": "rule.umbral-de-bajo-valor-mil-quinientas-udis", "rail": "mx-spei", "class": "Rule", "name": "One thousand five hundred UDIS marks a low value order and switches the clocks", "statement": "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.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 2a, fracción XXXIV", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "applies_to", "to": "mx-spei:txn.bajo-valor", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 2a fracción XXXIV, read 2026-09-20. The figure is recorded in the statement rather than as a typed limit because UDIS are an index unit, not a currency, and because the figure switches a deadline rather than capping an amount.", "confidence": "high" }, "currency": { "effective_since": "2022-12-13", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 15/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 2a fraccion XXXIV: an Orden de Transferencia de Bajo Valor is one addressed to a credit institution or sent or received by a mobile transfer clearing house for up to one thousand five hundred UDIS valued at 1 January of the issue year, and that this switches the five second crediting and ten second return clocks rather than capping the amount." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.umbral-de-seis-mil-udis-validaciones-adicionales", "id": "rule.umbral-de-seis-mil-udis-validaciones-adicionales", "rail": "mx-spei", "class": "Rule", "name": "Six thousand UDIS is the point at which a receiver may ask for longer to run extra checks", "statement": "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.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 19a, fracción I, third paragraph", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-receptor", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 19a fracción I, read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2025-02-21", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 2/2025, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 19a fraccion I third paragraph: at six thousand UDIS per transfer or accumulated to one beneficiary account in a day, a receiving participant running extra internal validations may ask the Administrador for up to six months longer to credit, on a request recording that it is automating those validations, using the 1 January UDI value." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.umbral-de-tres-mil-cuentas", "id": "rule.umbral-de-tres-mil-cuentas", "rail": "mx-spei", "class": "Rule", "name": "Three thousand customer accounts splits participants into two classes", "statement": "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.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Reglas 5a Bis, 15a, 19a, fracción II, and 25a, fracción III", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 5a Bis, 15a, 19a fracción II and 25a fracción III, read 2026-09-20. The figure counts accounts, not money, so it is not a typed limit.", "confidence": "high" }, "currency": { "effective_since": "2022-03-23", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Reglas 5a Bis, 15a, 19a fraccion II and 25a fraccion III: three thousand demand deposit or electronic payment funds accounts, counted per Regla 15a, decides whether a participant connects to every instance and sits inside or outside the round the clock five second crediting window and the 06:00:30 and 06:00:10 overnight clock times." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:rule.vinculo-al-cep-en-cinco-minutos", "id": "rule.vinculo-al-cep-en-cinco-minutos", "rail": "mx-spei", "class": "Rule", "name": "A link to the Banco de México receipt must sit against every settled transfer within five minutes", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Regla 85a", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-emisor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "mx-spei:role.participante-receptor", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 85a, read 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2025-02-21", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 2/2025, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 85a: participants operating through electronic channels must post the Apendice E link within five minutes of the settlement advice, keep it three months, and supply the Banco de Mexico portal the settlement date, Clave de Rastreo or Referencia Numerica, both participant names, the beneficiary identifier and the amount." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:src.cep-scl-guia", "id": "src.cep-scl-guia", "rail": "mx-spei", "class": "RuleSource", "name": "Guía de Operación para Usuarios del CEP-Servicio de Consulta por Lotes", "summary": "Banco de México's operating guide to the batch lookup of the Comprobante Electrónico de Pago, the receipt a customer can pull for a settled SPEI transfer. It sets the input file (one comma separated line per transfer carrying the transfer date, the Clave de Rastreo, the sending and receiving institution keys, the beneficiary account and the amount, UTF-8 without a byte order mark, up to 500 lines), the output as PDF or XML named by date and Clave de Rastreo, and the three reasons a CEP cannot be produced, the first of which is that the receiving participant has not sent its Confirmación de Abono. CEPs are available for transfers from 2018-03-16. In Spanish, marked Uso Público.", "publisher": "Banco de México, Dirección General de Sistemas de Pagos e Infraestructuras de Mercados", "url": "https://www.banxico.org.mx/apps/dgspim/%7B14726DC9-C3C0-D197-26F0-7BAEACF905C3%7D.pdf", "source_class": "public_primary", "kind": "operator_guide", "edition": "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", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The PDF, fetched with a plain compressed GET and read in full in Spanish on 2026-09-20. No form on the CEP portal was filled in and no lookup was run.", "confidence": "high" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for the mx-spei rail. A RuleSource describes one edition of one document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "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", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "mx-spei:rule.consulta-de-cep-por-lotes", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.sin-confirmacion-de-abono-no-hay-cep", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "mx-spei:src.guias-homologacion", "id": "src.guias-homologacion", "rail": "mx-spei", "class": "RuleSource", "name": "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", "summary": "Banco de México's mandatory user interface standard for instructing a transfer from a mobile application. Circular 9/2026 added the Guías to the Reglas as definition XXVII Quáter and made Reglas 7a, 10a and 71a require them. They set three principles and four stages, and they fix what the screen must show: the paying account, the beneficiary identifier and the receiving participant derived from it, the amount, concept and numeric reference, a confirmation screen before the customer authorises, and a result screen carrying the Clave de Rastreo and a link to the CEP. Version 1.1 adds generating a QR that carries the account identifier. In Spanish, marked Uso Público.", "publisher": "Banco de México", "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", "kind": "guideline", "edition": "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", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The version 1.1 PDF, fetched with a plain compressed GET and read in Spanish on 2026-09-20: the contents, section II scope, section V in full, the four flows named in section VI and the section VII version control table.", "confidence": "high" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for the mx-spei rail. A RuleSource describes one edition of one document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "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": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "mx-spei:rule.datos-a-confirmar-antes-de-autorizar", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.datos-en-la-notificacion-del-resultado", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.guias-de-homologacion-obligatorias", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.nombre-del-participante-receptor-desde-el-identificador", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "mx-spei:src.ley-sistemas-de-pagos", "id": "src.ley-sistemas-de-pagos", "rail": "mx-spei", "class": "RuleSource", "name": "Ley de Sistemas de Pagos", "summary": "The Mexican federal statute that gives SPEI its finality. Article 2 defines the Administrador del Sistema, the compensación, the liquidación and the accepted transfer order. Article 4 makes Banco de México publish each January the list of arrangements that count as payment systems under the law. Article 6 says a system's internal rules must be authorised by Banco de México and must state the moment an order becomes accepted. Article 11 makes accepted transfer orders and their compensación and liquidación firm, irrevocable, enforceable and effective against third parties, and holds off judicial, administrative and insolvency measures until the banking day after they are served on the Administrador. In Spanish.", "publisher": "Cámara de Diputados del H. Congreso de la Unión", "url": "https://www.diputados.gob.mx/LeyesBiblio/pdf/LSP.pdf", "source_class": "authoritative_primary", "kind": "statute", "edition": "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", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The consolidated text published by the Cámara de Diputados, fetched with a plain compressed GET and read in Spanish on 2026-09-20: articles 1 to 7 and 11 to 12 in full, and the reform note dating the last reform to 2025-11-14.", "confidence": "high" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for the mx-spei rail. A RuleSource describes one edition of one document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "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": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "mx-spei:rail.mx-spei", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:role.banco-de-mexico", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.firmeza-e-irrevocabilidad-legal", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.medidas-judiciales-desde-el-dia-siguiente", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "mx-spei:src.participantes-directos", "id": "src.participantes-directos", "rail": "mx-spei", "class": "RuleSource", "name": "Participantes directos en el SPEI, listado público", "summary": "Banco de México's public list of the institutions that hold a Cuenta del SPEI and send and receive transfer orders directly. The list dated 2026-09-10 carries 94 participants in eleven categories: 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 afore, 1 fondo y fideicomiso and 1 depósito de valores. In Spanish, marked Uso Público.", "publisher": "Banco de México", "url": "https://www.banxico.org.mx/servicios/d/%7BC24C7DBC-9ABF-6F41-DA38-561CEB1401B3%7D.pdf", "source_class": "public_primary", "kind": "participant_list", "edition": "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", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The PDF, fetched with a plain compressed GET and read in full on 2026-09-20; the header date, the total and every category count were read from the document itself.", "confidence": "high" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for the mx-spei rail. A RuleSource describes one edition of one document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "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": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "mx-spei:rail.mx-spei", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.noventa-y-cuatro-participantes-directos", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "mx-spei:src.reglas-spei", "id": "src.reglas-spei", "rail": "mx-spei", "class": "RuleSource", "name": "Circular 14/2017, Reglas del Sistema de Pagos Electrónicos Interbancarios (texto compilado)", "summary": "Banco de México's own rules for SPEI, issued by circular and consolidated on the Banxico site. They define the participants and the transfer order chain from Solicitud de Envío to Aviso de Liquidación, set settlement against the participants' Cuentas del SPEI with no overdrafts, state the statutory finality of a settled order, list the ten grounds on which a receiving participant must return a payment it could not credit, set every return and crediting deadline in seconds, set the operating day, the delay compensation and its formula, the customer information and CEP obligations, the fee prohibitions, the participant criteria and the SPEI quotas. Regla 1a states that the Reglas and the Manual together are the internal rules of SPEI, and the Manual is not public. In Spanish.", "publisher": "Banco de México", "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", "kind": "rulebook", "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", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The compiled text, fetched with a plain compressed GET and read in Spanish on 2026-09-20: Capítulo I definitions, Reglas 3a to 9a Bis, Reglas 10a to 33a in full, 34a to 39a, 43a and 44a, 56a and 57a, 70a and 71a, and 82a to 90a.", "confidence": "high" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for the mx-spei rail. A RuleSource describes one edition of one document; its status stays draft and the monthly watch dates it through consulted_on.", "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": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "mx-spei:rail.mx-spei", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:exc.devolucion-acreditada", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:exc.devolucion-no-acreditada", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:exc.eliminacion", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:exc.solicitud-de-apoyo", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:role.banco-de-mexico", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:role.cliente-beneficiario-indirecto", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:role.cliente-beneficiario", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:role.cliente-emisor-indirecto", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:role.cliente-emisor", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:role.participante-emisor", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:role.participante-indirecto", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:role.participante-receptor", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.abono-de-la-devolucion-acreditada", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.abono-de-la-devolucion-no-acreditada", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.ampliacion-o-suspension-del-horario", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.autorizacion-admision-y-contrato", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.aviso-de-falla-en-sesenta-segundos", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.aviso-de-la-causa-al-cliente-emisor", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.calculo-de-la-compensacion-por-demora", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.canales-y-plazos-de-la-informacion", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.cancelacion-solo-antes-de-la-liquidacion", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.catalogo-de-causas-de-devolucion-no-publico", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.causas-de-devolucion-no-acreditada", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.clave-de-rastreo-y-referencia-numerica", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.compensacion-por-demora-al-cliente", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.compensacion-por-demora-entre-participantes", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.conexion-a-las-instancias-del-spei", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.contrato-unilateral-de-confidencialidad", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.convenio-de-colaboracion-obligatorio", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.criterios-para-ser-participante", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.cuotas-del-spei", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.devolucion-acreditada-extemporanea", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.devolucion-de-transferencia-acreditada", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.devolucion-extemporanea-lleva-la-compensacion", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.dia-de-operacion-del-spei", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.el-administrador-queda-liberado", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.el-convenio-puede-fijar-plazos-menores", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.el-emisor-verifica-y-decide-aceptar-la-solicitud", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.el-receptor-puede-rechazar-tipos-opcionales", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.eliminacion-de-ordenes-no-liquidadas", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.fondeo-de-las-cuentas-del-spei", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.formatos-y-tipos-en-el-manual", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.guias-de-homologacion-obligatorias", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.horarios-en-hora-de-la-ciudad-de-mexico", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.informacion-de-la-transferencia-al-cliente", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.la-devolucion-vuelve-por-la-misma-instancia", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.limite-de-saldo-por-cliente", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.liquidacion-contra-el-saldo-de-la-instancia", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.orden-aceptada-por-spei", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.pagina-de-aclaraciones-y-reclamaciones", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.participacion-indirecta", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.plazo-de-devolucion-no-acreditada", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.razon-de-la-no-acreditacion-y-canal-gratuito", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.reintento-de-una-devolucion-eliminada", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.sin-comisiones-por-enviar-recibir-devolver-o-abonar", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.sin-confirmacion-de-abono-no-hay-cep", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.sin-sobregiros-en-la-cuenta-del-spei", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.suspension-de-solicitudes-durante-una-falla", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.ultimos-cinco-minutos-sin-compensacion", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.umbral-de-bajo-valor-mil-quinientas-udis", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.umbral-de-seis-mil-udis-validaciones-adicionales", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.umbral-de-tres-mil-cuentas", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.vinculo-al-cep-en-cinco-minutos", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:txn.bajo-valor", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:txn.codi", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:txn.devolucion", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:txn.pago-programado", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:txn.tercero-a-tercero", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "mx-spei:src.spei-pfmi", "id": "src.spei-pfmi", "rail": "mx-spei", "class": "RuleSource", "name": "SPEI, divulgación del cumplimiento y adopción de los Principios para las Infraestructuras del Mercado Financiero", "summary": "Banco de México's disclosure of how SPEI meets the CPMI and IOSCO Principles for Financial Market Infrastructures. It is the only public Banco de México document that describes SPEI's settlement mechanics in prose: a hybrid system that settles in central bank money on the participants' own accounts, grants no credit and allows no overdraft, averaged 1.9 seconds to settle a payment, offers a high priority flag and reserved balance, supports V and T send topologies, and cancels every unsettled payment at the change of operating day. Its disclosure date is 2016-03-28, which is before six of the eleven amending circulares and before the SPEI instances existed, so every line taken from it is dated. In Spanish.", "publisher": "Banco de México", "url": "https://www.banxico.org.mx/sistemas-de-pago/d/%7B89B6CCF0-6070-7389-3DD5-B27AC4ECD9D1%7D.pdf", "source_class": "public_primary", "kind": "pfmi_disclosure", "edition": "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", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The PDF, fetched with a plain compressed GET and read in Spanish on 2026-09-20: the executive summary, section III on the general organisation, the description of the markets SPEI serves and the general system design.", "confidence": "high" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for the mx-spei rail. A RuleSource describes one edition of one document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "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": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "mx-spei:role.banco-de-mexico", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.liquidacion-casi-en-tiempo-real", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:rule.sin-sobregiros-en-la-cuenta-del-spei", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "mx-spei:txn.tercero-a-tercero", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "mx-spei:txn.bajo-valor", "id": "txn.bajo-valor", "rail": "mx-spei", "class": "TransactionType", "name": "Orden de Transferencia de Bajo Valor", "summary": "A transfer of up to the equivalent of one thousand five hundred UDIS, valued at 1 January of the year the order is issued, 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. It is not a separate product but a threshold that switches the clocks: the receiving credit institution or clearing house must credit within five seconds, twenty four hours a day every day of the year, and must return within ten seconds rather than sixty during the 06:00:00 to 17:59:50 window.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Reglas 2a, fracción XXXIV, 19a, fracción II, and 25a, fracción III", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 2a fracción XXXIV, 19a fracción II and 25a fracción III, read 2026-09-20. sec_code is null.", "confidence": "high" }, "currency": { "effective_since": "2022-12-13", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 15/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 2a fraccion XXXIV, 19a fraccion II and 25a fraccion III: an Orden de Transferencia de Bajo Valor is up to 1,500 UDIS addressed to a credit institution or a mobile clearing house, crediting in five seconds around the clock and returning in ten seconds in the 06:00:00 to 17:59:50 window." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "mx-spei:rule.umbral-de-bajo-valor-mil-quinientas-udis", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "mx-spei:txn.codi", "id": "txn.codi", "rail": "mx-spei", "class": "TransactionType", "name": "Orden de Transferencia CoDi", "summary": "The request to pay flow inside SPEI, not a rail beside it. A Cliente Beneficiario enables a mobile device with the Administrador and generates a Mensaje de Cobro; when the payer accepts it, the payer's participant sends an Orden de Transferencia CoDi. It is governed by the same Reglas with its own deadlines throughout, in four, eight and ten seconds where an ordinary transfer gets five, thirty and sixty, its own processing advices under Apéndice AD of the Manual, its own elimination rule after the next clearing cycle, a lower delay compensation floor of one daily UMA, and exemption from customer fees and from the per operation quota on returns.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Reglas 2a, fracción XXX Bis, 7a Bis, 9a Bis, 17a, 25a, fracción VII, 27a, 30a, 31a, 86a, 88a and 90a", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 2a fracción XXX Bis, 7a Bis, 9a Bis, 17a, 25a fracción VII, 27a, 30a, 31a, 86a, 88a and 90a, read 2026-09-20. sec_code is null. Chief of Staff decision of 2026-09-20: CoDi is a TransactionType inside mx-spei, not a rail of its own, because one rulebook governs both.", "confidence": "high" }, "currency": { "effective_since": "2022-03-23", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 2a fraccion XXX Bis, 7a Bis and 9a Bis describe the CoDi Mensaje de Cobro and acceptance flow, and that Reglas 17a, 25a fraccion VII, 27a, 30a, 31a, 86a, 88a and 90a give CoDi orders their own four, eight and ten second deadlines, their own elimination point, a lower one-UMA compensation floor, and fee and quota exemptions." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:txn.devolucion", "id": "txn.devolucion", "rail": "mx-spei", "class": "TransactionType", "name": "Orden de Transferencia del tipo devolución", "summary": "A return on SPEI is a new transfer order sent by the receiving side, not a reversal of the original. The Reglas name four types and which one applies decides the deadline, who may start it and the amount: devolución de transferencia no acreditada en la Cuenta del Cliente, its extemporánea variant, devolución de transferencia acreditada en Cuentas de Clientes, and its extemporánea variant. The two extemporánea types must carry the original amount plus the Regla 87a compensation. All four use formats in section 8 of the Manual and go back through the instance the original used, save in the cases section 5.16.4 of the Manual allows. sec_code is null and directions is credit, because a return is a fresh push in the opposite direction rather than a debit.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Reglas 23a, 24a, 26a, 28a, 29a and 30a", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 23a, 24a, 26a, 28a, 29a and 30a, read 2026-09-20. Four named types are held as one record with the variants stated, because they share a format section, an instance rule and a purpose.", "confidence": "high" }, "currency": { "effective_since": "2022-03-23", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 1/2022, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Reglas 23a, 24a, 26a, 28a, 29a and 30a describe the four named return order types (not credited, its extemporanea variant, credited, its extemporanea variant), that the two extemporanea types carry the original amount plus the Regla 87a compensation, and that returns use section 8 Manual formats and go back through the originating instance except under section 5.16.4." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "mx-spei:rule.devolucion-acreditada-extemporanea", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:rule.devolucion-extemporanea-lleva-la-compensacion", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "mx-spei:txn.pago-programado", "id": "txn.pago-programado", "rail": "mx-spei", "class": "TransactionType", "name": "Pago Programado", "summary": "A transfer order that Banco de México sends as Participante Emisor to credit a participant's Cuenta Alterna del SPEI. It is the only order type an alternate account may receive: anything else arriving there, apart from a devolución a participant sends from its own alternate account, is a mandatory return ground, and the return deadline for a scheduled payment is 06:00:10 rather than sixty seconds.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Reglas 2a, fracción XXXV, 23a, fracción VI, and 25a, fracción IV", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 2a fracción XXXV, 23a fracción VI and 25a fracción IV, read 2026-09-20. sec_code is null.", "confidence": "high" }, "currency": { "effective_since": "2019-05-20", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 8/2019, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Regla 2a fraccion XXXV defines Pago Programado as an order Banco de Mexico sends as Participante Emisor to credit a Cuenta Alterna del SPEI, that Regla 23a fraccion VI makes any other order reaching that account a mandatory return ground, and that Regla 25a fraccion IV sets its 06:00:10 return deadline." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "mx-spei:txn.tercero-a-tercero", "id": "txn.tercero-a-tercero", "rail": "mx-spei", "class": "TransactionType", "name": "Orden de Transferencia tercero a tercero", "summary": "The ordinary customer to customer transfer, and the type Regla 7a makes the operating process run on: the sending participant's customer presents a Solicitud de Envío, the participant sends the order, the Administrador settles it and issues the Aviso de Liquidación, and the receiving participant credits the beneficiary. sec_code is null because SPEI has no entry class codes; the type names live in section 8 of the Manual, which is not public. directions is credit: SPEI carries no debit pull.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "mx-spei:src.reglas-spei", "section": "Reglas 5a, 7a and 19a, fracción I", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "mx-spei:src.spei-pfmi", "section": "section III.B, note 8 on the payment types", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Reglas del SPEI 5a, 7a and 19a fracción I; SPEI PFMI disclosure of 2016-03-28, section III.B; read 2026-09-20. sec_code is null: SPEI has no entry class codes and the type names are in the unpublished Manual.", "confidence": "high" }, "currency": { "effective_since": "2026-06-17", "effective_to": null, "effective_note": "Drafted 2026-09-20 in Orca Core form from the compiled text of Circular 14/2017. The date is the day the Diario Oficial de la Federación published Circular 9/2026, which last set the wording of the provision cited. Circular 9/2026 says a circular takes effect on the banking day after publication, and the transitorios of the other amending circulares were not read, so the operative date may fall one banking day later [Unverified].", "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": "mx-spei:src.reglas-spei", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms Reglas 5a, 7a and 19a fraccion I describe the ordinary customer to customer transfer's send, settle, advise and credit chain." }, { "source": "mx-spei:src.spei-pfmi", "checked_on": "2026-09-21", "checked_by": "mx-spei validator session, 2026-09-21", "notes": "Confirms section III.B describes the third party to third party payment flow using the V send topology, matching the record's payment type description." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "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.", "rules": [ "mx-spei:rule.informacion-de-la-transferencia-al-cliente", "mx-spei:rule.canales-y-plazos-de-la-informacion", "mx-spei:rule.razon-de-la-no-acreditacion-y-canal-gratuito", "mx-spei:rule.pagina-de-aclaraciones-y-reclamaciones", "mx-spei:rule.vinculo-al-cep-en-cinco-minutos", "mx-spei:rule.sin-comisiones-por-enviar-recibir-devolver-o-abonar", "mx-spei:rule.guias-de-homologacion-obligatorias", "mx-spei:rule.nombre-del-participante-receptor-desde-el-identificador", "mx-spei:rule.datos-a-confirmar-antes-de-autorizar", "mx-spei:rule.datos-en-la-notificacion-del-resultado" ], "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.", "relations": [ { "type": "see_also", "to": "pix:consumer-law", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mx-spei:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "mx-spei:src.reglas-spei", "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": "mx-spei:src.guias-homologacion", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "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.", "rules": [ "mx-spei:rule.el-emisor-verifica-y-decide-aceptar-la-solicitud", "mx-spei:rule.cancelacion-solo-antes-de-la-liquidacion", "mx-spei:rule.el-receptor-puede-rechazar-tipos-opcionales", "mx-spei:rule.umbral-de-seis-mil-udis-validaciones-adicionales", "mx-spei:rule.convenio-de-colaboracion-obligatorio", "mx-spei:rule.devolucion-de-transferencia-acreditada", "mx-spei:rule.ampliacion-o-suspension-del-horario", "mx-spei:rule.eliminacion-de-ordenes-no-liquidadas" ], "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.", "relations": [ { "type": "see_also", "to": "pix:decision-points", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "mx-spei:src.reglas-spei", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "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.", "rules": [ "mx-spei:rule.orden-aceptada-por-spei", "mx-spei:rule.firmeza-e-irrevocabilidad-legal", "mx-spei:rule.medidas-judiciales-desde-el-dia-siguiente", "mx-spei:rule.sin-sobregiros-en-la-cuenta-del-spei", "mx-spei:rule.cancelacion-solo-antes-de-la-liquidacion" ], "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.", "relations": [ { "type": "see_also", "to": "pix:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mx-spei:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "mx-spei:src.ley-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": "mx-spei:src.reglas-spei", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "mx-spei:recall", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "mx-spei:rule.dia-de-operacion-del-spei", "mx-spei:rule.horarios-en-hora-de-la-ciudad-de-mexico", "mx-spei:rule.ampliacion-o-suspension-del-horario", "mx-spei:rule.umbral-de-tres-mil-cuentas" ], "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.", "relations": [ { "type": "see_also", "to": "pix:hours", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "mx-spei:src.reglas-spei", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "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.", "rules": [ "mx-spei:rule.el-administrador-queda-liberado", "mx-spei:rule.compensacion-por-demora-al-cliente", "mx-spei:rule.compensacion-por-demora-entre-participantes", "mx-spei:rule.calculo-de-la-compensacion-por-demora", "mx-spei:rule.devolucion-extemporanea-lleva-la-compensacion", "mx-spei:rule.ultimos-cinco-minutos-sin-compensacion", "mx-spei:rule.aviso-de-falla-en-sesenta-segundos", "mx-spei:rule.suspension-de-solicitudes-durante-una-falla" ], "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).", "relations": [ { "type": "see_also", "to": "pix:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mx-spei:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "mx-spei:src.reglas-spei", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "mx-spei:return", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "mx-spei:rule.umbral-de-bajo-valor-mil-quinientas-udis", "mx-spei:rule.umbral-de-seis-mil-udis-validaciones-adicionales", "mx-spei:rule.umbral-de-tres-mil-cuentas", "mx-spei:rule.limite-de-saldo-por-cliente" ], "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.", "relations": [ { "type": "see_also", "to": "pix:limits", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "mx-spei:src.reglas-spei", "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": "mx-spei:src.guias-homologacion", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "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.", "rules": [ "mx-spei:rule.formatos-y-tipos-en-el-manual", "mx-spei:rule.catalogo-de-causas-de-devolucion-no-publico", "mx-spei:rule.clave-de-rastreo-y-referencia-numerica", "mx-spei:rule.consulta-de-cep-por-lotes", "mx-spei:rule.sin-confirmacion-de-abono-no-hay-cep", "mx-spei:rule.vinculo-al-cep-en-cinco-minutos", "mx-spei:rule.datos-en-la-notificacion-del-resultado" ], "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.", "relations": [ { "type": "see_also", "to": "pix:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mx-spei:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "mx-spei:src.reglas-spei", "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": "mx-spei:src.cep-scl-guia", "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": "mx-spei:src.guias-homologacion", "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": "mx-spei:src.spei-pfmi", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "mx-spei:consumer-law", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "mx-spei:rule.criterios-para-ser-participante", "mx-spei:rule.autorizacion-admision-y-contrato", "mx-spei:rule.contrato-unilateral-de-confidencialidad", "mx-spei:rule.noventa-y-cuatro-participantes-directos", "mx-spei:rule.umbral-de-tres-mil-cuentas", "mx-spei:rule.conexion-a-las-instancias-del-spei", "mx-spei:rule.participacion-indirecta", "mx-spei:rule.cuotas-del-spei" ], "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.", "relations": [ { "type": "see_also", "to": "pix:participants", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "mx-spei:src.reglas-spei", "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": "mx-spei:src.participantes-directos", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "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.", "rules": [ "mx-spei:rule.cancelacion-solo-antes-de-la-liquidacion", "mx-spei:rule.firmeza-e-irrevocabilidad-legal", "mx-spei:rule.causas-de-devolucion-no-acreditada", "mx-spei:rule.devolucion-de-transferencia-acreditada", "mx-spei:rule.convenio-de-colaboracion-obligatorio" ], "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.", "relations": [ { "type": "see_also", "to": "mx-spei:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "mx-spei:src.reglas-spei", "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": "mx-spei:src.ley-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "mx-spei:finality", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "mx-spei:rule.convenio-de-colaboracion-obligatorio", "mx-spei:rule.el-convenio-puede-fijar-plazos-menores", "mx-spei:rule.devolucion-de-transferencia-acreditada", "mx-spei:rule.devolucion-acreditada-extemporanea" ], "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.", "relations": [ { "type": "see_also", "to": "pix:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mx-spei:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "mx-spei:src.reglas-spei", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "mx-spei:return", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "mx-spei:rule.causas-de-devolucion-no-acreditada", "mx-spei:rule.catalogo-de-causas-de-devolucion-no-publico", "mx-spei:rule.plazo-de-devolucion-no-acreditada", "mx-spei:rule.devolucion-extemporanea-lleva-la-compensacion", "mx-spei:rule.abono-de-la-devolucion-no-acreditada", "mx-spei:rule.aviso-de-la-causa-al-cliente-emisor", "mx-spei:rule.devolucion-de-transferencia-acreditada", "mx-spei:rule.devolucion-acreditada-extemporanea", "mx-spei:rule.abono-de-la-devolucion-acreditada", "mx-spei:rule.reintento-de-una-devolucion-eliminada", "mx-spei:rule.la-devolucion-vuelve-por-la-misma-instancia" ], "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.", "relations": [ { "type": "see_also", "to": "pix:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mx-spei:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "mx-spei:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "mx-spei:src.reglas-spei", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "mx-spei:liability", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:messages", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:refund", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "mx-spei:rule.liquidacion-contra-el-saldo-de-la-instancia", "mx-spei:rule.sin-sobregiros-en-la-cuenta-del-spei", "mx-spei:rule.fondeo-de-las-cuentas-del-spei", "mx-spei:rule.eliminacion-de-ordenes-no-liquidadas", "mx-spei:rule.conexion-a-las-instancias-del-spei", "mx-spei:rule.liquidacion-casi-en-tiempo-real" ], "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.", "relations": [ { "type": "see_also", "to": "pix:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "mx-spei:src.reglas-spei", "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": "mx-spei:src.spei-pfmi", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rail.pix", "id": "rail.pix", "class": "Rail", "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" } ] }, "country": "Brazil", "currency": "BRL", "operators": [ "Banco Central do Brasil" ], "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "arts. 1 to 3 and the annexed Regulamento Pix", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "section": "art. 2 inciso I and Chapter II, on what the SPI is and who runs it", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "source_class": null, "effective_status_reason": null, "used_by": [] }, { "uid": "pix:codeset.pain011-cancellation-reasons", "id": "codeset.pain011-cancellation-reasons", "rail": "pix", "class": "CodeSet", "name": "Pix Automatico cancellation reasons (pain.011)", "summary": "The eleven reasons a pain.011 may give for cancelling a Pix Automatico recurrence, or a journey 1 request still pending. The same list is used whichever side asks; who asked travels in a separate field. Unchanged between catalogs 5.12.1 and 5.13.1.", "values": [ { "code": "ACCL", "name": "the payer's or the business's account was closed", "terminal": true }, { "code": "CPCL", "name": "the business has shut down", "terminal": true }, { "code": "DCSD", "name": "the payer has died", "terminal": true }, { "code": "ERSL", "name": "the business or its bank withdrew a pending request that contained an error", "terminal": true }, { "code": "FRUD", "name": "suspected fraud", "terminal": true }, { "code": "NRES", "name": "the business's bank withdrew a pending request the payer's bank never acknowledged in time", "terminal": true }, { "code": "OTHS", "name": "any other reason; only where no other code fits", "terminal": true }, { "code": "PCFD", "name": "the business's bank withdrew a pending request because the payer authorised the same recurrence another way, such as by QR code", "terminal": true }, { "code": "SJUD", "name": "a court order", "terminal": true }, { "code": "SLCR", "name": "the business asked for it", "terminal": true }, { "code": "SLDB", "name": "the payer asked for it", "terminal": true } ], "owner": "Banco Central do Brasil", "complete": true, "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "section": "PAIN011.xlsx, Tabela de Dominios, CancellationReason Proprietary (MotivoCancelamentoCode), in 5.12.1 and 5.13.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "pix:rule.automatico-either-side-may-cancel-the-authorisation", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:mandate.pix-automatico-authorisation", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The pain.011 domain table in spi.5.12.1.zip and spi.5.13.1.zip, read 2026-09-22; eleven codes in both.", "confidence": "high" }, "currency": { "effective_since": "2026-06-28", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. Values are the domain table's codes with names written in English in Orca's own words. effective_since is the production date of 5.12.1, the first catalog read; when the codes first appeared was not traced.", "source_edition": "SPI message definitions spi.5.12.1.zip (in production since 2026-06-28) and spi.5.13.1.zip (production from 2026-10-25), domain tables", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms in the PAIN011.xlsx domain table of both spi.5.12.1.zip and spi.5.13.1.zip that CancellationReason Proprietary lists the same eleven codes, ACCL, CPCL, DCSD, ERSL, FRUD, NRES, OTHS, PCFD, SJUD, SLCR and SLDB, unchanged between the two catalogs, with who cancelled carried in a separate field" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:mandate.pix-automatico-authorisation", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:codeset.pain012-authorisation-rejection-reasons-from-2026", "id": "codeset.pain012-authorisation-rejection-reasons-from-2026", "rail": "pix", "class": "CodeSet", "name": "Pix Automatico authorisation rejection reasons (pain.012), catalog 5.13.1", "summary": "From 2026-10-25, when SPI catalog 5.13.1 goes into production, a pain.012 refusing a Pix Automatico authorisation request, a confirmation or a cancellation draws on 23 reasons. All 23 are carried over unchanged from catalog 5.12.1; the four the SPI itself used to fill (AG12, DS27, RC09 and RC10) are gone, so every reason left is filled by a participant: the payer's bank, the business's bank, or either, as the domain table says for each. The catalog's change log gives the reason for the removals as alignment with the validation model the SPI uses for Pix Automatico flows, which answers through admi.002.", "values": [ { "code": "AC01", "name": "account not found or not the payer's" }, { "code": "AC04", "name": "payer's account closed" }, { "code": "AC06", "name": "payer's account blocked" }, { "code": "AM05", "name": "request already confirmed or already pending" }, { "code": "AP01", "name": "update timestamp inconsistent with the recurrence status" }, { "code": "AP02", "name": "payer's CPF or CNPJ not found or not the one on the request or recurrence" }, { "code": "AP03", "name": "payer's branch not found" }, { "code": "AP04", "name": "recurrence identifier invalid or not the original" }, { "code": "AP05", "name": "recurrence status inconsistent" }, { "code": "AP06", "name": "business's CPF or CNPJ not the one on the request, payload or recurrence" }, { "code": "AP07", "name": "payer confirmed after the request expired or was withdrawn" }, { "code": "AP08", "name": "journey 3 first immediate payment not found" }, { "code": "AP09", "name": "pending request to be cancelled not found" }, { "code": "AP10", "name": "whoever asked to cancel is not a party to the recurrence" }, { "code": "AP11", "name": "payer's bank ISPB differs from the recurrence" }, { "code": "AP12", "name": "business's bank ISPB differs from the recurrence" }, { "code": "AP13", "name": "payer does not recognise the business" }, { "code": "AP14", "name": "payer does not want Pix Automatico for this business" }, { "code": "AP15", "name": "payer's bank does not offer Pix Automatico to this business customer" }, { "code": "CH16", "name": "content formally wrong or against the business rules; the catch-all" }, { "code": "MD01", "name": "recurrence to be cancelled does not exist" }, { "code": "MD20", "name": "recurrence to be cancelled has already expired" }, { "code": "SA01", "name": "a salary account cannot pay Pix Automatico" } ], "owner": "Banco Central do Brasil", "complete": true, "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "section": "PAIN012.xlsx, Tabela de Dominios, RejectReason Proprietary (MotivoRejeicaoCode), in 5.13.1; NotasVersaoDiff5.13.1v5.12.1.xlsx, sheet pain.012, Alteracoes de Dominios", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-comunicacao-eletronica-de-dados", "section": "Catalogo de Servicos do SFN, Versao 5.13 schedule: SPI production date", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:codeset.pain012-authorisation-rejection-reasons", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:rule.automatico-three-refusal-families-and-who-raises-them", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:mandate.pix-automatico-authorisation", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Catalog 5.13.1 (spi.5.13.1.zip, dated 2026-07-24), read 2026-09-24: the PAIN012.xlsx domain table, which holds 23 codes, and the change log spreadsheet NotasVersaoDiff5.13.1v5.12.1.xlsx, whose pain.012 sheet lists exactly the removals named in summary and no other domain change for this field. The code names are the ones pix:codeset.pain012-authorisation-rejection-reasons already gives in Orca's own words, checked against the 5.13.1 descriptions; the note on admi.002 restates the change log's stated reason and goes no further. complete is true for 5.13.1.", "confidence": "high" }, "currency": { "effective_since": "2026-10-25", "effective_to": null, "effective_note": "Drafted 2026-09-24 for change calendar decision 3 from the documents named in basis. Published 2026-07-24 (catalog 5.13.1); in SPI production 2026-10-25, the date the BCB comunicacaodados page, read 2026-09-24, gives for version 5.13 on the SPI. Until then pix:codeset.pain012-authorisation-rejection-reasons governs. The Core schema allows supersedes only between Rules, so this CodeSet names the one it replaces through see_also.", "source_edition": "SPI message definitions spi.5.13.1.zip (dated 2026-07-24, SPI production from 2026-10-25), domain tables and NotasVersaoDiff5.13.1v5.12.1.xlsx", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Parsed PAIN012.xlsx Tabela de Dominios in spi.5.13.1.zip from the row-level sheet XML and confirms the RejectReason Proprietary domain holds exactly the 23 listed codes, unchanged from catalog 5.12.1, which holds 27 including the four removed: AG12, DS27, RC09 and RC10. Parsed NotasVersaoDiff5.13.1v5.12.1.xlsx, sheet pain.012, and confirms all four removals are recorded there with the same stated reason, alignment with the validation model the SPI uses for Pix Automatico flows answering through admi.002, and no other domain change for this field." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:codeset.pain012-authorisation-rejection-reasons", "id": "codeset.pain012-authorisation-rejection-reasons", "rail": "pix", "class": "CodeSet", "name": "Pix Automatico authorisation rejection reasons (pain.012)", "summary": "The reasons a pain.012 may give for refusing a Pix Automatico authorisation request, a confirmation or a cancellation, 27 in catalog 5.12.1. The domain table names who fills each: most by the payer's bank, some by the business's bank or by either, and AG12, DS27, RC09 and RC10 by the SPI. Catalog 5.13.1, in production from 2026-10-25, drops those four, leaving 23.", "values": [ { "code": "AC01", "name": "account not found or not the payer's" }, { "code": "AC04", "name": "payer's account closed" }, { "code": "AC06", "name": "payer's account blocked" }, { "code": "AG12", "name": "both accounts at one participant or one settling participant (SPI; gone in 5.13.1)" }, { "code": "AM05", "name": "request already confirmed or already pending" }, { "code": "AP01", "name": "update timestamp inconsistent with the recurrence status" }, { "code": "AP02", "name": "payer's CPF or CNPJ not found or not the one on the request or recurrence" }, { "code": "AP03", "name": "payer's branch not found" }, { "code": "AP04", "name": "recurrence identifier invalid or not the original" }, { "code": "AP05", "name": "recurrence status inconsistent" }, { "code": "AP06", "name": "business's CPF or CNPJ not the one on the request, payload or recurrence" }, { "code": "AP07", "name": "payer confirmed after the request expired or was withdrawn" }, { "code": "AP08", "name": "journey 3 first immediate payment not found" }, { "code": "AP09", "name": "pending request to be cancelled not found" }, { "code": "AP10", "name": "whoever asked to cancel is not a party to the recurrence" }, { "code": "AP11", "name": "payer's bank ISPB differs from the recurrence" }, { "code": "AP12", "name": "business's bank ISPB differs from the recurrence" }, { "code": "AP13", "name": "payer does not recognise the business" }, { "code": "AP14", "name": "payer does not want Pix Automatico for this business" }, { "code": "AP15", "name": "payer's bank does not offer Pix Automatico to this business customer" }, { "code": "CH16", "name": "content formally wrong or against the business rules; the catch-all" }, { "code": "DS27", "name": "participant not registered or not yet live on the SPI (SPI; gone in 5.13.1)" }, { "code": "MD01", "name": "recurrence to be cancelled does not exist" }, { "code": "MD20", "name": "recurrence to be cancelled has already expired" }, { "code": "RC09", "name": "payer's bank ISPB invalid (SPI; gone in 5.13.1)" }, { "code": "RC10", "name": "business's bank ISPB invalid (SPI; gone in 5.13.1)" }, { "code": "SA01", "name": "a salary account cannot pay Pix Automatico" } ], "owner": "Banco Central do Brasil", "complete": true, "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "section": "PAIN012.xlsx, Tabela de Dominios, RejectReason Proprietary (MotivoRejeicaoCode), in 5.12.1 and 5.13.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "pix:rule.automatico-three-refusal-families-and-who-raises-them", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:mandate.pix-automatico-authorisation", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The pain.012 domain table in spi.5.12.1.zip (27 codes) and spi.5.13.1.zip (23), read 2026-09-22. complete is true for 5.12.1, the catalog in production on 2026-09-22.", "confidence": "high" }, "currency": { "effective_since": "2026-06-28", "effective_to": "2026-10-25", "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. Values are the domain table's codes with names written in English in Orca's own words. effective_since is the production date of 5.12.1; on 2026-10-25 the four SPI codes leave the list and this record needs a dated successor. Stops applying 2026-10-25, the SPI production date of catalog 5.13.1; the draft successor is pix:codeset.pain012-authorisation-rejection-reasons-from-2026.", "source_edition": "SPI message definitions spi.5.12.1.zip (in production since 2026-06-28) and spi.5.13.1.zip (production from 2026-10-25), domain tables", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms in the PAIN012.xlsx domain table 27 reject reasons in catalog 5.12.1 with AG12 marked as raised by the SPI and DS27, RC09 and RC10 following the same SPI-registration pattern used elsewhere in this catalog, and confirms in the 5.13.1 domain table that those four codes are absent, leaving 23" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:codeset.pain012-authorisation-rejection-reasons-from-2026", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:codeset.pain014-instruction-errors-from-2026", "id": "codeset.pain014-instruction-errors-from-2026", "rail": "pix", "class": "CodeSet", "name": "Pix Automatico instruction errors (pain.014), catalog 5.13.1", "summary": "From 2026-10-25, when SPI catalog 5.13.1 goes into production, a pain.014 refusing a Pix Automatico payment instruction (pain.013) instead of scheduling it draws on 20 error codes, every one filled by the payer's bank. They are the 20 payer's bank codes of catalog 5.12.1, unchanged; the five the SPI used to fill (AG12, AM23, DS27, RC09 and RR06) are gone. The catalog's change log gives the reason as alignment with the validation model the SPI uses for Pix Automatico flows, which answers through admi.002. As before, none of the codes is about the payer's balance.", "values": [ { "code": "AB10", "name": "error at the payer's bank" }, { "code": "AC05", "name": "payer's account closed" }, { "code": "AC06", "name": "payer's account blocked" }, { "code": "AM02", "name": "amount above the payer's maximum" }, { "code": "AM09", "name": "amount differs from the fixed amount of the recurrence" }, { "code": "CRNC", "name": "business's CNPJ differs from the recurrence" }, { "code": "DENC", "name": "payer's CPF or CNPJ differs from the recurrence" }, { "code": "DTED", "name": "due date does not fit the period or the product rules" }, { "code": "DTNT", "name": "retry from the eighth day after the due date" }, { "code": "FCD1", "name": "instruction more than 10 days before settlement" }, { "code": "FCD2", "name": "instruction less than 2 days before settlement" }, { "code": "GRER", "name": "generic error; only where no other code fits" }, { "code": "IRNT", "name": "the recurrence does not allow retries after the due date" }, { "code": "MIDI", "name": "recurrence identifier missing or wrong" }, { "code": "MSUC", "name": "recurrence not confirmed by the payer" }, { "code": "NIEC", "name": "new instruction while the earlier one's order is still waiting to go to the SPI" }, { "code": "NIPA", "name": "new instruction for a charge already paid" }, { "code": "NITX", "name": "new instruction does not match an earlier recurring charge" }, { "code": "QUNT", "name": "more than 3 retries within 7 days of the due date" }, { "code": "UDEI", "name": "debtor's CPF or CNPJ wrong" } ], "owner": "Banco Central do Brasil", "complete": true, "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "section": "PAIN014.xlsx, Tabela de Dominios, StatusReasonInformation Reason Proprietary (CodigoDeErroPain014Code), in 5.13.1; NotasVersaoDiff5.13.1v5.12.1.xlsx, sheet pain.014, Alteracoes de Dominios", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-comunicacao-eletronica-de-dados", "section": "Catalogo de Servicos do SFN, Versao 5.13 schedule: SPI production date", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:codeset.pain014-instruction-errors", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:rule.automatico-three-refusal-families-and-who-raises-them", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:rule.automatico-the-payers-bank-schedules-within-2-hours-or-refuses", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:mandate.pix-automatico-authorisation", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Catalog 5.13.1 (spi.5.13.1.zip, dated 2026-07-24), read 2026-09-24: the PAIN014.xlsx domain table, which holds 20 codes, and the change log spreadsheet NotasVersaoDiff5.13.1v5.12.1.xlsx, whose pain.014 sheet lists exactly the removals named in summary and no other domain change for this field. The code names are the ones pix:codeset.pain014-instruction-errors already gives in Orca's own words, checked against the 5.13.1 descriptions; the note on admi.002 restates the change log's stated reason and goes no further. complete is true for 5.13.1.", "confidence": "high" }, "currency": { "effective_since": "2026-10-25", "effective_to": null, "effective_note": "Drafted 2026-09-24 for change calendar decision 3 from the documents named in basis. Published 2026-07-24 (catalog 5.13.1); in SPI production 2026-10-25, the date the BCB comunicacaodados page, read 2026-09-24, gives for version 5.13 on the SPI. Until then pix:codeset.pain014-instruction-errors governs. The Core schema allows supersedes only between Rules, so this CodeSet names the one it replaces through see_also.", "source_edition": "SPI message definitions spi.5.13.1.zip (dated 2026-07-24, SPI production from 2026-10-25), domain tables and NotasVersaoDiff5.13.1v5.12.1.xlsx", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Parsed PAIN014.xlsx Tabela de Dominios in spi.5.13.1.zip from the row-level sheet XML and confirms the payer's bank error domain holds exactly the 20 listed codes, unchanged from catalog 5.12.1, which holds 25 including the five removed: AG12, AM23, DS27, RC09 and RR06. Parsed NotasVersaoDiff5.13.1v5.12.1.xlsx, sheet pain.014, and confirms all five removals are recorded there with the same stated reason, alignment with the validation model the SPI uses for Pix Automatico flows answering through admi.002, and no other domain change for this field. Confirms none of the 20 codes concerns the payer's account balance." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:codeset.pain014-instruction-errors", "id": "codeset.pain014-instruction-errors", "rail": "pix", "class": "CodeSet", "name": "Pix Automatico instruction errors (pain.014)", "summary": "The errors a pain.014 may give when a Pix Automatico payment instruction (pain.013) is refused rather than scheduled, 25 in catalog 5.12.1. Twenty are filled by the payer's bank; AG12, AM23, DS27, RC09 and RR06 by the SPI, and catalog 5.13.1, in production from 2026-10-25, drops those five, leaving 20. None is about the payer's balance: funds are tested on the settlement day, not at scheduling.", "values": [ { "code": "AB10", "name": "error at the payer's bank" }, { "code": "AC05", "name": "payer's account closed" }, { "code": "AC06", "name": "payer's account blocked" }, { "code": "AG12", "name": "both accounts at one participant or one settling participant (SPI; gone in 5.13.1)" }, { "code": "AM02", "name": "amount above the payer's maximum" }, { "code": "AM09", "name": "amount differs from the fixed amount of the recurrence" }, { "code": "AM23", "name": "declared taxes add up to more than the payment (SPI; gone in 5.13.1)" }, { "code": "CRNC", "name": "business's CNPJ differs from the recurrence" }, { "code": "DENC", "name": "payer's CPF or CNPJ differs from the recurrence" }, { "code": "DS27", "name": "participant not registered or not yet live on the SPI (SPI; gone in 5.13.1)" }, { "code": "DTED", "name": "due date does not fit the period or the product rules" }, { "code": "DTNT", "name": "retry from the eighth day after the due date" }, { "code": "FCD1", "name": "instruction more than 10 days before settlement" }, { "code": "FCD2", "name": "instruction less than 2 days before settlement" }, { "code": "GRER", "name": "generic error; only where no other code fits" }, { "code": "IRNT", "name": "the recurrence does not allow retries after the due date" }, { "code": "MIDI", "name": "recurrence identifier missing or wrong" }, { "code": "MSUC", "name": "recurrence not confirmed by the payer" }, { "code": "NIEC", "name": "new instruction while the earlier one's order is still waiting to go to the SPI" }, { "code": "NIPA", "name": "new instruction for a charge already paid" }, { "code": "NITX", "name": "new instruction does not match an earlier recurring charge" }, { "code": "QUNT", "name": "more than 3 retries within 7 days of the due date" }, { "code": "RC09", "name": "payer's bank ISPB invalid (SPI; gone in 5.13.1)" }, { "code": "RR06", "name": "tax block used where payer and business are not both legal persons (SPI; gone in 5.13.1)" }, { "code": "UDEI", "name": "debtor's CPF or CNPJ wrong" } ], "owner": "Banco Central do Brasil", "complete": true, "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "section": "PAIN014.xlsx, Tabela de Dominios, StatusReasonInformation Reason Proprietary (CodigoDeErroPain014Code), in 5.12.1 and 5.13.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "pix:rule.automatico-three-refusal-families-and-who-raises-them", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:rule.automatico-the-payers-bank-schedules-within-2-hours-or-refuses", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:mandate.pix-automatico-authorisation", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The pain.014 domain table in spi.5.12.1.zip (25 codes) and spi.5.13.1.zip (20), read 2026-09-22. complete is true for 5.12.1. That no code concerns the balance is read from the list itself against IN BCB n. 513/2024 art. 7.", "confidence": "high" }, "currency": { "effective_since": "2026-06-28", "effective_to": "2026-10-25", "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. Values are the domain table's codes with names written in English in Orca's own words. effective_since is the production date of 5.12.1; on 2026-10-25 the five SPI codes leave the list and this record needs a dated successor. Stops applying 2026-10-25, the SPI production date of catalog 5.13.1; the draft successor is pix:codeset.pain014-instruction-errors-from-2026.", "source_edition": "SPI message definitions spi.5.12.1.zip (in production since 2026-06-28) and spi.5.13.1.zip (production from 2026-10-25), domain tables", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms in the PAIN014.xlsx domain table 25 error codes in catalog 5.12.1 including AG12, AM23, DS27, RC09 and RR06, and confirms in the 5.13.1 domain table that those five codes are absent, leaving 20, and that no code in either version tests the payer balance at scheduling time" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:codeset.pain014-instruction-errors-from-2026", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:exc.bloqueio-cautelar", "id": "exc.bloqueio-cautelar", "rail": "pix", "class": "Exception", "name": "Bloqueio cautelar (precautionary hold)", "summary": "The receiving end user's participant freezes a credited amount it suspects, at the moment it credits it, for no more than 72 hours, while it decides whether the suspicion is well founded.", "money_moves": false, "outcome": "The money is frozen but not moved. At the end of the window the participant either releases it to its customer or sends it back.", "relations": [ { "type": "initiated_by", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Written by the 2026-09 Orca Core migration from the pix rail facts whose detail lines describe this path; no source was opened for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Regulamento Pix (Resolucao BCB n. 1/2020) consolidated version 41; Regulamento do SPI (Resolucao BCB n. 195/2022); Manual de Tempos do Pix 7.0; Manual Operacional do DICT 8.5; Catalogo de Servicos do SFN Vol. VI 5.12", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 39-B confirms the receiving participant freezes suspect funds at the moment of credit for up to 72 hours while it assesses whether the suspicion is well founded, and confirms that participant both raises and evaluates the freeze." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:rule.consumer-law-a-freeze-the-customer-never-has-to-ask-for", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.decision-points-what-to-do-at-the-end-of-72-hours", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.decision-points-whether-to-freeze-money-as-it-lands", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.finality-third-layer-the-money-can-be-frozen-the-instant", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.liability-the-duty-to-freeze-on-arrival", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.liability-the-hold-is-no-longer-limited-to-individuals", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:exc.devolucao", "id": "exc.devolucao", "rail": "pix", "class": "Exception", "name": "Devolucao (return)", "summary": "The receiving end user asks its own participant to send value back, on its own initiative or at the payer's request. It is a fresh credit in the opposite direction, not a reversal of the original payment.", "money_moves": true, "outcome": "Value travels back to the payer as a new payment message; the original Pix stands, and a partial return may be repeated until the original amount is reached.", "relations": [ { "type": "initiated_by", "to": "pix:role.receiving-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Written by the 2026-09 Orca Core migration from the pix rail facts whose detail lines describe this path; no source was opened for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Regulamento Pix (Resolucao BCB n. 1/2020) consolidated version 41; Regulamento do SPI (Resolucao BCB n. 195/2022); Manual de Tempos do Pix 7.0; Manual Operacional do DICT 8.5; Catalogo de Servicos do SFN Vol. VI 5.12", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 40 par. 1 confirms an ordinary devolucao is started by the receiving end user, on its own initiative or at the payer's request, and confirms it as a new credit rather than an undoing of the original payment; the receiving participant is the one that executes it under art. 41." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:rule.finality-second-layer-a-return-is-a-new-payment-not-a", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.limits-limits-an-operator-will-not-see-in-a-return", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.messages-the-return-pair-and-its-four-reasons", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.refund-everything-else-presupposes-funds", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.return-a-return-travels-on-the-fast-channel-and-is", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.return-funds-must-actually-be-there", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.return-partial-and-repeated-returns", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.return-pix-saque-and-pix-troco-a-different-starter-and", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.return-pix-troco-needs-two-returns", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.return-returns-do-not-consume-the-payers-limits", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.return-the-90-day-window", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.return-the-reason-code-an-operator-will-see", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.return-what-the-receiving-users-bank-then-does", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.return-who-may-start-one", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:exc.med", "id": "exc.med", "rail": "pix", "class": "Exception", "name": "Mecanismo Especial de Devolucao and Recuperacao de Valores", "summary": "The payer's participant asks, through the DICT rather than through a payment message, for value to come back after settlement, on well founded suspicion of fraud, on a participant's operational failure, or on a Pix Automatico payment sent without a valid authorization.", "money_moves": true, "outcome": "Where the grounds are made out and money remains, value travels back to the payer's participant; where they are not, the request is closed with a stated reason and nothing moves.", "relations": [ { "type": "initiated_by", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Written by the 2026-09 Orca Core migration from the pix rail facts whose detail lines describe this path; no source was opened for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Regulamento Pix (Resolucao BCB n. 1/2020) consolidated version 41; Regulamento do SPI (Resolucao BCB n. 195/2022); Manual de Tempos do Pix 7.0; Manual Operacional do DICT 8.5; Catalogo de Servicos do SFN Vol. VI 5.12", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 41-B confirms the three MED grounds, fraud, operational failure and a faulty Pix Automatico payment, and art. 41-C confirms the payer participant is usually the one that requests it through the DICT while the receiving participant decides on the request." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:mandate.pix-automatico-authorisation", "type": "disputed_via", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-a-faulty-payment-is-refunded-within-24-hours", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.consumer-law-a-complaint-can-start-a-recovery", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.decision-points-whether-to-cancel-a-recovery-you-opened", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.decision-points-whether-to-honour-a-return-request-at-all", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.decision-points-whether-to-open-a-recovery-on-the-customers-word", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.finality-fourth-layer-finality-does-not-settle-who-bears", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.liability-pix-automatico-the-payers-bank-pays-first", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.liability-the-requesting-participant-owns-the-med-return", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.recall-asking-freezes-money-immediately", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.recall-for-fraud-the-dict-drives-the-whole-thing", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.recall-the-recovering-bank-must-police-its-own-request", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.recall-the-request-goes-over-dict-not-over-iso", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.recall-the-window-to-ask-is-80-days", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.recall-two-grounds-it-never-covers", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.recall-what-the-special-mechanism-is-for", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.recall-who-actually-sends-the-money-back", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.refund-accepting-even-with-no-money-is-expected", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.refund-four-different-ways-the-money-travels", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.refund-grounds-a-receiving-bank-may-give-for-paying", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.refund-how-much-each-bank-has-to-pay-back", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.refund-money-must-be-unblocked-at-only-three-moments", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.refund-the-72-hour-clock-on-the-return-stage", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.refund-the-operational-failure-route-is-narrower-than", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:exc.notificacao-de-infracao", "id": "exc.notificacao-de-infracao", "rail": "pix", "class": "Exception", "name": "Notificacao de infracao (infraction notice)", "summary": "One participant tells another, over the DICT, that an account it holds was used in a fraud. It carries no money and runs on its own footing beside any request for the funds.", "money_moves": false, "outcome": "An accepted or self raised notice marks the account in the DICT and shuts it out of Pix; a rejection without just cause leaves the rejecting participant answerable.", "relations": [ { "type": "initiated_by", "to": "pix:role.pix-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Written by the 2026-09 Orca Core migration from the pix rail facts whose detail lines describe this path; no source was opened for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Regulamento Pix (Resolucao BCB n. 1/2020) consolidated version 41; Regulamento do SPI (Resolucao BCB n. 195/2022); Manual de Tempos do Pix 7.0; Manual Operacional do DICT 8.5; Catalogo de Servicos do SFN Vol. VI 5.12", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-manual-operacional-dict-8-5", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Section 10 confirms an infraction notice is raised by a participant over the DICT to flag another participant's account, that a fraud marker notice moves no money by itself, and section 17 confirms the receiving participant decides whether to accept or reject it, running alongside any separate return request." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:rule.decision-points-whether-to-accept-an-infraction-notice-about", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.decision-points-whether-to-lift-a-block-on-a-flagged-account", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.liability-a-bad-rejection-makes-the-receiving-bank", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.liability-an-accepted-notice-shuts-the-account-out-of-pix", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.recall-fraud-marking-is-a-separate-thing-from-asking", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.refund-rejecting-the-refund-does-not-undo-the-fraud", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:mandate.pix-automatico-authorisation", "id": "mandate.pix-automatico-authorisation", "rail": "pix", "class": "Mandate", "name": "Pix Automatico authorisation", "summary": "The standing consent behind Pix Automatico. The payer gives it once, to their own bank, before the first collection; it lets that bank pay, without asking the payer again, each instruction the named business's bank sends within its terms, and it is at the same time the payer's permission for that business to keep sending instructions. Nothing is pulled: every payment is a credit push the payer's bank makes. The payer can cancel it at any time and change some of its settings on their own; the business can have it cancelled too.", "form": "A recurrence record the business creates at its bank through the API Pix (identifier starting with R; one created under Open Finance starts with C), which becomes an authorisation when the payer confirms it in their own bank's logged-in Pix app through one of four journeys. The two banks keep it in step with pain.009, pain.011 and pain.012 messages through the SPI; the confirming pain.012 records which journey was used. The payer's bank holds the authorisation and shows it under the Pix Automatico menu; the business's bank holds the recurrence. Its identifier is shown to the payer.", "scope": [ "payments to one named business, a legal person whose CNPJ has been active for at least six months, for one stated purpose that may bundle several products or services billed together", "one charge per cycle, on a period chosen from weekly, monthly, quarterly, half-yearly and yearly, from a first payment date the authorisation states, for a set term or until cancelled", "a fixed amount, or variable amounts under a maximum the payer may set and the business may put a floor under", "optionally, funding from a pre-approved credit line when the balance falls short, if the payer leaves that on", "optionally, retries on up to three later dates within seven days of a missed due date, if the business's policy provides for it", "credit pushes by the payer's bank only; no collection is ever debited by the business or its bank" ], "constraints": { "recurrence": { "max_occurrences": null, "text": "The period is one of five, closed by IN BCB n. 513/2024 art. 2: weekly, monthly, quarterly, half-yearly or yearly. The typed field cannot hold the half-yearly value and cannot say one of five, so no period is typed. One charge per cycle; the number of cycles follows from the term, which may be open." }, "counterparties": { "text": "Exactly one business, named in the authorisation by its CNPJ as the Federal Revenue registers it; an instruction naming anyone else is refused (pain.014 CRNC). The payer and the debtor may differ, and both are shown." } }, "relations": [ { "type": "given_by", "to": "pix:role.payer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "given_to", "to": "pix:role.payer-psp", "note": "Regulamento art. 11-Q par. 1 inciso I: the authorisation is given to the payer's own bank.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "given_to", "to": "pix:role.receiving-user", "note": "The same act is the permission the business needs to send instructions (art. 11-Q par. 1 inciso III). given_to cannot say which of the two it is, so both are linked with a note.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "authorises", "to": "pix:txn.pix-automatico", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "pix:rule.automatico-a-standing-authorisation-not-a-debit-pull", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "pix:rule.automatico-four-journeys-to-an-authorisation", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "pix:rule.automatico-a-pending-request-lapses-after-30-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "pix:rule.automatico-journey-3-needs-the-first-payment-to-settle", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "pix:rule.automatico-what-an-authorisation-must-state", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "pix:rule.automatico-five-recurrence-periods", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "pix:rule.automatico-a-cycle-on-a-day-the-month-lacks", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "pix:rule.automatico-the-payer-sets-the-maximum-the-business-sets-its-floor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "pix:rule.automatico-what-the-payer-may-edit-and-when-it-bites", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "pix:rule.automatico-a-pre-approved-credit-line-may-fund-it", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "pix:rule.automatico-who-may-offer-and-who-may-collect", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "pix:rule.automatico-instructions-go-2-to-10-days-ahead", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "pix:rule.automatico-settlement-date-is-the-due-date", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "pix:rule.automatico-the-payers-bank-schedules-within-2-hours-or-refuses", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "pix:rule.automatico-settles-between-00-and-08-with-an-evening-retry", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "pix:rule.automatico-retries-on-later-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "pix:rule.automatico-a-settlement-error-allows-a-same-day-resend", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "pix:rule.automatico-cancelling-one-scheduled-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "pix:rule.automatico-three-refusal-families-and-who-raises-them", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "pix:rule.messages-pix-automatico-authorization-messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "pix:rule.messages-pix-automatico-instruction-messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "pix:rule.limits-the-user-can-drive-the-limit-in-both-directions", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "revoked_via", "to": "pix:rule.automatico-either-side-may-cancel-the-authorisation", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "revoked_via", "to": "pix:rule.automatico-cancelling-the-authorisation-stops-what-is-scheduled", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "disputed_via", "to": "pix:exc.med", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:codeset.pain011-cancellation-reasons", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "arts. 11-Q to 11-V", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "section": "arts. 2 to 11 and 15-A", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "section": "sections 2.4.3 and 2.8, Annex I section 5.1, Annex IV sections 2 and 4", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-requisitos-minimos-experiencia-usuario-7-3", "section": "chapter 15", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Regulamento Pix arts. 11-Q to 11-V, IN BCB n. 513/2024 arts. 2 to 11 and 15-A, the Manual de Padroes para Iniciacao do Pix 2.10.0 and chapter 15 of the Requisitos Minimos 7.3, all read in Portuguese on 2026-09-22. The typed constraints carry only what those sources give: no amount figure exists, and the build refuses an amount range with neither bound, so the fixed or variable amount, the payer's optional maximum and the business's floor under it are prose in scope; and the recurrence period is a closed list of five that the typed field cannot hold, so both are prose. The Regulamento's word for what the payer gives the bank is autorizacao and for what the business receives is permissao; this record treats them as one act, as art. 11-Q par. 1 inciso III does.", "confidence": "high" }, "currency": { "effective_since": "2025-06-16", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. The Regulamento's Pix Automatico subsection was added by Resolucao BCB n. 402 of 22/7/2024, and IN BCB n. 513/2024 art. 17 II puts the Pix Automatico procedures in force on 2025-06-16, which is used here as the date the product's rules began to bind.", "source_edition": "Regulamento Pix annexed to Resolucao BCB n. 1/2020, consolidated text as served on 2026-09-22, Chapter V, Section II; Instrucao Normativa BCB n. 513 de 30/8/2024, consolidated text version 5.0 as served on 2026-09-22, with the amendments by IN BCB n. 614/2025, n. 634/2025 and n. 743/2026 shown in place; Manual de Padroes para Iniciacao do Pix version 2.10.0 of 2026-08-19; Requisitos Minimos para a Experiencia do Usuario version 7.3 of December 2025; its cover announces version 7.4 in force from 2027-03-01", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms art 11-Q caput and par 1 incisos I to III that the standing consent is given once to the payer's own bank before the first instruction, lets that bank act on each matching instruction without further authentication, and is also the payer's permission for the business to keep sending instructions, par 1 IV that the payer may cancel or alter it unilaterally, and par 1 V that the payer bank must cancel it when the business withdraws its permission" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:codeset.pain011-cancellation-reasons", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:codeset.pain012-authorisation-rejection-reasons-from-2026", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:codeset.pain012-authorisation-rejection-reasons", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:codeset.pain014-instruction-errors-from-2026", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:codeset.pain014-instruction-errors", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:role.bcb", "id": "role.bcb", "rail": "pix", "class": "Role", "name": "Banco Central do Brasil", "summary": "The central bank that owns the Pix arrangement, writes its rules, operates the SPI and the DICT, holds every Conta PI and settles every payment. Authority, operator and settlement agent are one institution here.", "kind": "authority", "relations": [], "basis": { "sources": "Written by the 2026-09 Orca Core migration from the pix rail facts whose detail lines name this role; no source was opened for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Regulamento Pix (Resolucao BCB n. 1/2020) consolidated version 41; Regulamento do SPI (Resolucao BCB n. 195/2022); Manual de Tempos do Pix 7.0; Manual Operacional do DICT 8.5; Catalogo de Servicos do SFN Vol. VI 5.12", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 5 confirms the Banco Central do Brasil is the SPI's manager and operator, and art. 2 inciso VI confirms every Conta PI is held at the Banco Central do Brasil; the Regulamento Pix names the same institution as the author of the Pix rules." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:rule.decision-points-where-the-dict-decides-instead-of-a-person", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.finality-how-fast-that-has-to-happen", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.finality-the-moment-of-finality", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.finality-the-system-presumes-the-order-is-good", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.hours-the-dict-never-closes-either", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.hours-the-spi-never-closes", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.liability-non-compliance-is-a-supervision-matter", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.limits-the-network-sets-no-ceiling", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.messages-two-catalogs-alive-at-once", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.participants-payment-institutions-can-join-before-they-are", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.participants-who-has-to-join", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.recall-for-fraud-the-dict-drives-the-whole-thing", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.settlement-balance-checks-need-not-follow-arrival-order", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.settlement-step-one-the-spi-blocks-the-sending-banks-funds", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.settlement-step-three-the-balance-swap-is-settlement", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.settlement-what-the-spi-is", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:role.direct-participant", "id": "role.direct-participant", "rail": "pix", "class": "Role", "name": "Direct participant in the SPI", "summary": "A participant that holds its own Conta PI at the BCB and settles in the SPI on its own account.", "kind": "institution", "relations": [], "basis": { "sources": "Written by the 2026-09 Orca Core migration from the pix rail facts whose detail lines name this role; no source was opened for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Regulamento Pix (Resolucao BCB n. 1/2020) consolidated version 41; Regulamento do SPI (Resolucao BCB n. 195/2022); Manual de Tempos do Pix 7.0; Manual Operacional do DICT 8.5; Catalogo de Servicos do SFN Vol. VI 5.12", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 14 inciso I confirms a direct participant is defined by owning a Conta PI and a direct connection to the SPI, and art. 2 incisos VI and VII confirm the Conta PI and direct participant definitions." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:rule.hours-availability-is-measured-and-has-a-floor", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.hours-banks-must-be-open-too", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.participants-direct-or-indirect-is-a-separate-question", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.participants-what-a-direct-spi-participant-signs-up-to", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.settlement-liquidity-for-the-conta-pi", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:role.indirect-participant", "id": "role.indirect-participant", "rail": "pix", "class": "Role", "name": "Indirect participant in the SPI", "summary": "A participant that reaches the SPI through a direct participant, which settles for it.", "kind": "institution", "relations": [], "basis": { "sources": "Written by the 2026-09 Orca Core migration from the pix rail facts whose detail lines name this role; no source was opened for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Regulamento Pix (Resolucao BCB n. 1/2020) consolidated version 41; Regulamento do SPI (Resolucao BCB n. 195/2022); Manual de Tempos do Pix 7.0; Manual Operacional do DICT 8.5; Catalogo de Servicos do SFN Vol. VI 5.12", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 14 inciso II confirms an indirect participant has no Conta PI and reaches the SPI through a direct participant that acts as its settling participant." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:rule.participants-direct-or-indirect-is-a-separate-question", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:role.payer-psp", "id": "role.payer-psp", "rail": "pix", "class": "Role", "name": "PSP do pagador", "summary": "The participant that holds the paying end user's transactional account, authorises the payment on its own side and sends the order into the SPI.", "kind": "institution", "relations": [], "basis": { "sources": "Written by the 2026-09 Orca Core migration from the pix rail facts whose detail lines name this role; no source was opened for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Regulamento Pix (Resolucao BCB n. 1/2020) consolidated version 41; Regulamento do SPI (Resolucao BCB n. 195/2022); Manual de Tempos do Pix 7.0; Manual Operacional do DICT 8.5; Catalogo de Servicos do SFN Vol. VI 5.12", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 36 confirms the payer end user's participant performs the security checks and balance check that authorise a Pix on its own side; the messages sections elsewhere confirm this same participant issues the pacs.008 that starts the SPI order." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:exc.med", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "pix:mandate.pix-automatico-authorisation", "type": "given_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.agendado-a-repeat-date-the-month-lacks-moves-to-the-1st", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.agendado-and-scheduled-charges-settle-00-to-08-with-an-evening-retry", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-a-faulty-payment-is-refunded-within-24-hours", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-a-pending-request-lapses-after-30-days", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-a-pre-approved-credit-line-may-fund-it", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-a-settlement-error-allows-a-same-day-resend", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-a-standing-authorisation-not-a-debit-pull", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-cancelling-one-scheduled-payment", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-cancelling-the-authorisation-stops-what-is-scheduled", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-either-side-may-cancel-the-authorisation", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-four-journeys-to-an-authorisation", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-journey-3-needs-the-first-payment-to-settle", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-retries-on-later-days", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-settles-between-00-and-08-with-an-evening-retry", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-the-pacs008-is-marked-auto", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-the-payer-sets-the-maximum-the-business-sets-its-floor", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-the-payers-bank-schedules-within-2-hours-or-refuses", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-what-an-authorisation-must-state", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-what-the-payer-may-edit-and-when-it-bites", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-who-may-offer-and-who-may-collect", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.cobranca-a-due-date-charge-rolls-to-the-payers-next-business-day", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.consumer-law-a-complaint-can-start-a-recovery", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.consumer-law-the-limit-panel-must-be-where-the-customer-from-2026", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.consumer-law-the-limit-panel-must-be-where-the-customer", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.consumer-law-the-night-ceiling-is-the-single-most-concrete", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.decision-points-whether-to-cancel-a-recovery-you-opened", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.decision-points-whether-to-hold-a-payment-before-it-settles", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.decision-points-whether-to-open-a-recovery-on-the-customers-word", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.decision-points-whether-to-raise-a-customers-limit", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.finality-one-cancellation-window-does-exist-before", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.hours-the-fraud-hold-runs-on-business-hours", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.hours-the-night-period-is-a-value-rule-not-a-closing", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.liability-pix-automatico-the-payers-bank-pays-first", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.liability-the-duty-to-reject-on-both-sides", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.liability-the-requesting-participant-owns-the-med-return", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.limits-contactless-and-initiation-without-redirection-from-2026", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.limits-contactless-and-initiation-without-redirection", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.limits-cuts-are-immediate-increases-are-slow-on-purpose", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.limits-the-day-limit-is-no-longer-pegged-to-ted", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.limits-the-night-limit-for-person-to-person", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.limits-the-user-can-drive-the-limit-in-both-directions-from-2026", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.limits-the-user-can-drive-the-limit-in-both-directions", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.limits-withdrawal-and-change-carry-hard-ceilings", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.recall-the-recovering-bank-must-police-its-own-request", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.settlement-the-banks-own-authorization-step-comes-first", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:role.payer", "id": "role.payer", "rail": "pix", "class": "Role", "name": "Usuario pagador", "summary": "The end user, a person or a business, whose account a Pix leaves.", "kind": "party", "relations": [], "basis": { "sources": "Written by the 2026-09 Orca Core migration from the pix rail facts whose detail lines name this role; no source was opened for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Regulamento Pix (Resolucao BCB n. 1/2020) consolidated version 41; Regulamento do SPI (Resolucao BCB n. 195/2022); Manual de Tempos do Pix 7.0; Manual Operacional do DICT 8.5; Catalogo de Servicos do SFN Vol. VI 5.12", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 36 and the surrounding chapters use usuario pagador throughout for the end user, natural person or legal entity, whose transactional account a Pix debits." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:mandate.pix-automatico-authorisation", "type": "given_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:role.pix-participant", "id": "role.pix-participant", "rail": "pix", "class": "Role", "name": "Participante do Pix", "summary": "An institution admitted to the Pix arrangement in any modality, bound by the Regulamento and the manuals under it.", "kind": "institution", "relations": [], "basis": { "sources": "Written by the 2026-09 Orca Core migration from the pix rail facts whose detail lines name this role; no source was opened for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Regulamento Pix (Resolucao BCB n. 1/2020) consolidated version 41; Regulamento do SPI (Resolucao BCB n. 195/2022); Manual de Tempos do Pix 7.0; Manual Operacional do DICT 8.5; Catalogo de Servicos do SFN Vol. VI 5.12", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 3 confirms participation is mandatory for institutions meeting the stated threshold and open to others admitted in the modalities the Regulamento sets, and the Regulamento and its manuals bind every admitted participant throughout." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:exc.notificacao-de-infracao", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.cobranca-immediate-and-due-date-charges", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.consumer-law-a-fee-rule-and-a-disclosure-rule", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.consumer-law-the-general-customer-protection-resolution-has-a", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.consumer-law-the-rulebook-obliges-a-good-experience-in-terms", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.hours-what-a-bank-must-offer-its-own-customers-is", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.liability-access-devices-must-be-registered", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.liability-an-accepted-notice-shuts-the-account-out-of-pix", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.liability-fraud-risk-management-is-a-stated-obligation", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.liability-where-disagreements-go", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.limits-a-ceiling-aimed-at-the-weakest-technical-link", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.limits-why-a-bank-may-set-a-limit-at-all", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.messages-the-standard-and-the-envelope", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.participants-leaving-takes-90-days-and-does-not-end", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.settlement-service-levels-not-just-deadlines", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:role.receiver-psp", "id": "role.receiver-psp", "rail": "pix", "class": "Role", "name": "PSP do recebedor", "summary": "The participant that holds the receiving end user's account, confirms it can take the payment, credits it, and decides on holds, returns and recovery requests against it.", "kind": "institution", "relations": [], "basis": { "sources": "Written by the 2026-09 Orca Core migration from the pix rail facts whose detail lines name this role; no source was opened for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Regulamento Pix (Resolucao BCB n. 1/2020) consolidated version 41; Regulamento do SPI (Resolucao BCB n. 195/2022); Manual de Tempos do Pix 7.0; Manual Operacional do DICT 8.5; Catalogo de Servicos do SFN Vol. VI 5.12", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 39-B confirms the receiving end user's participant is the one that freezes suspect funds, art. 40 and 41 confirm it is the one that executes an ordinary return, and the Manual Operacional do DICT sections 17 and 20.1 confirm it is the one that decides on return requests and infraction notices." }, { "source": "pix:src.bcb-manual-operacional-dict-8-5", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Sections 17 and 20.1 confirm the receiving end user's participant analyses and answers return requests and decides whether to accept infraction notices." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:exc.bloqueio-cautelar", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "pix:exc.bloqueio-cautelar", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "pix:exc.devolucao", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "pix:exc.med", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "pix:exc.notificacao-de-infracao", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-a-settlement-error-allows-a-same-day-resend", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-a-standing-authorisation-not-a-debit-pull", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-cancelling-one-scheduled-payment", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-either-side-may-cancel-the-authorisation", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-four-journeys-to-an-authorisation", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-instructions-go-2-to-10-days-ahead", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-journey-3-needs-the-first-payment-to-settle", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-retries-on-later-days", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-settlement-date-is-the-due-date", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-who-may-offer-and-who-may-collect", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.cobranca-a-charge-takes-one-payment-and-an-identifier-is-never-reused", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.cobranca-a-due-date-charge-rolls-to-the-payers-next-business-day", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.cobranca-an-immediate-charge-lives-24-hours-by-default", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.cobranca-the-payees-bank-computes-the-final-amount", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.consumer-law-a-freeze-the-customer-never-has-to-ask-for", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.decision-points-is-the-suspicion-well-founded", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.decision-points-what-to-do-at-the-end-of-72-hours", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.decision-points-whether-to-accept-an-infraction-notice-about", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.decision-points-whether-to-freeze-money-as-it-lands", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.decision-points-whether-to-honour-a-return-request-at-all", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.decision-points-whether-to-lift-a-block-on-a-flagged-account", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.finality-third-layer-the-money-can-be-frozen-the-instant", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.liability-a-bad-rejection-makes-the-receiving-bank", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.liability-the-duty-to-freeze-on-arrival", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.liability-the-duty-to-reject-on-both-sides", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.recall-asking-freezes-money-immediately", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.recall-who-actually-sends-the-money-back", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.refund-accepting-even-with-no-money-is-expected", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.refund-grounds-a-receiving-bank-may-give-for-paying", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.refund-money-must-be-unblocked-at-only-three-moments", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.refund-the-72-hour-clock-on-the-return-stage", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.refund-the-operational-failure-route-is-narrower-than", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.return-what-the-receiving-users-bank-then-does", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.settlement-step-two-the-receiving-bank-confirms-it-can-take", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:role.receiving-user", "id": "role.receiving-user", "rail": "pix", "class": "Role", "name": "Usuario recebedor", "summary": "The end user whose account a Pix credits, and the only party that may start an ordinary return.", "kind": "party", "relations": [], "basis": { "sources": "Written by the 2026-09 Orca Core migration from the pix rail facts whose detail lines name this role; no source was opened for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Regulamento Pix (Resolucao BCB n. 1/2020) consolidated version 41; Regulamento do SPI (Resolucao BCB n. 195/2022); Manual de Tempos do Pix 7.0; Manual Operacional do DICT 8.5; Catalogo de Servicos do SFN Vol. VI 5.12", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 40 par. 1 confirms an ordinary return must be started by the receiving end user, on its own or at the payer's request." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:exc.devolucao", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "pix:mandate.pix-automatico-authorisation", "type": "given_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.cobranca-a-static-code-leaves-reconciliation-to-the-receiver", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.return-who-may-start-one", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:role.responsible-participant", "id": "role.responsible-participant", "rail": "pix", "class": "Role", "name": "Responsible participant", "summary": "The participant that vouches for a smaller institution's admission to Pix and stays answerable for it.", "kind": "institution", "relations": [], "basis": { "sources": "Written by the 2026-09 Orca Core migration from the pix rail facts whose detail lines name this role; no source was opened for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Regulamento Pix (Resolucao BCB n. 1/2020) consolidated version 41; Regulamento do SPI (Resolucao BCB n. 195/2022); Manual de Tempos do Pix 7.0; Manual Operacional do DICT 8.5; Catalogo de Servicos do SFN Vol. VI 5.12", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 28 and art. 29 confirm the contract between a responsible participant and a smaller contracting participant governs the latter's admission and the notice a responsible participant owes before ending service." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:rule.participants-a-responsible-participant-that-walks-away-owes", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.participants-somebody-has-to-vouch-for-a-smaller-institution", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.participants-who-is-allowed-to-be-a-responsible-participant", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:role.settling-participant", "id": "role.settling-participant", "rail": "pix", "class": "Role", "name": "Settling participant", "summary": "The direct participant that settles for others. Where two participants share one, payments between them settle in its own systems rather than in the SPI.", "kind": "institution", "relations": [], "basis": { "sources": "Written by the 2026-09 Orca Core migration from the pix rail facts whose detail lines name this role; no source was opened for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Regulamento Pix (Resolucao BCB n. 1/2020) consolidated version 41; Regulamento do SPI (Resolucao BCB n. 195/2022); Manual de Tempos do Pix 7.0; Manual Operacional do DICT 8.5; Catalogo de Servicos do SFN Vol. VI 5.12", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 33 par. unico confirms that where two participants share the same settling participant in the SPI, payments between them settle in that settling participant's own systems rather than through the SPI." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:rule.messages-reporting-payments-that-never-touched-the-spi", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.settlement-settlement-outside-the-spi", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:role.withdrawal-agent", "id": "role.withdrawal-agent", "rail": "pix", "class": "Role", "name": "Withdrawal agent", "summary": "The establishment that hands over the cash in a Pix Saque or the cash half of a Pix Troco.", "kind": "agent", "relations": [], "basis": { "sources": "Written by the 2026-09 Orca Core migration from the pix rail facts whose detail lines name this role; no source was opened for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Regulamento Pix (Resolucao BCB n. 1/2020) consolidated version 41; Regulamento do SPI (Resolucao BCB n. 195/2022); Manual de Tempos do Pix 7.0; Manual Operacional do DICT 8.5; Catalogo de Servicos do SFN Vol. VI 5.12", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "The definitions article, inciso XXVII, confirms an agente de saque is a legal entity that contracts with a withdrawal facilitator to carry out the withdrawal or change service, and inciso XXV confirms that service is making cash available to the payer under Pix Saque or Pix Troco." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:rule.return-pix-saque-and-pix-troco-a-different-starter-and", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:role.withdrawal-facilitator", "id": "role.withdrawal-facilitator", "rail": "pix", "class": "Role", "name": "Withdrawal facilitator", "summary": "The institution that offers a cash withdrawal against a Pix and is answerable for starting the return when one is due.", "kind": "service_provider", "relations": [], "basis": { "sources": "Written by the 2026-09 Orca Core migration from the pix rail facts whose detail lines name this role; no source was opened for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Regulamento Pix (Resolucao BCB n. 1/2020) consolidated version 41; Regulamento do SPI (Resolucao BCB n. 195/2022); Manual de Tempos do Pix 7.0; Manual Operacional do DICT 8.5; Catalogo de Servicos do SFN Vol. VI 5.12", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "The definitions article, inciso XXVI, confirms a facilitador de servico de saque is a transactional account provider authorised by the BCB that optionally offers the withdrawal service directly or through an agent, and art. 41 par. 2 confirms it must start the return once it verifies one is due." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:rule.return-pix-saque-and-pix-troco-a-different-starter-and", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.agendado-a-repeat-date-the-month-lacks-moves-to-the-1st", "id": "rule.agendado-a-repeat-date-the-month-lacks-moves-to-the-1st", "rail": "pix", "class": "Rule", "name": "Pix Agendado: a repeating payment on the 29th, 30th or 31st", "statement": "Where a payer has set a Pix Agendado to repeat on the 29th, 30th or 31st and the month has no such day, the payment goes on the 1st of the following month. A bank may let the payer bring it forward instead. This is the Pix Agendado rule only; Pix Automatico handles the same gap differently.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "section": "art. 13", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-agendado", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:rule.automatico-a-cycle-on-a-day-the-month-lacks", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "IN BCB n. 513/2024 art. 13, read 2026-09-22.", "confidence": "high" }, "currency": { "effective_since": "2024-10-28", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. IN BCB n. 513/2024 art. 17 I puts arts. 12 to 14 in force on 2024-10-28.", "source_edition": "Instrucao Normativa BCB n. 513 de 30/8/2024, consolidated text version 5.0 as served on 2026-09-22, with the amendments by IN BCB n. 614/2025, n. 634/2025 and n. 743/2026 shown in place", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "pix:rule.automatico-a-cycle-on-a-day-the-month-lacks", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.agendado-and-scheduled-charges-settle-00-to-08-with-an-evening-retry", "id": "rule.agendado-and-scheduled-charges-settle-00-to-08-with-an-evening-retry", "rail": "pix", "class": "Rule", "name": "Pix Agendado and scheduled due date charges: the settlement window and the evening retry", "statement": "A Pix the payer schedules for a date, and a charge with a due date that the payer chose to schedule, are sent for settlement on that date between 00:00 and 08:00 if the balance and the limit allow. If the balance is short, or an operational failure intervened, the payer is told and the bank tries at least once more between 18:00 and 21:00, with 21:00 the last moment. If the limit is what is short, the payer is told. The payer can cancel such a scheduled payment up to 23:59 on the day before. The difference from Pix Automatico is who is in charge: here the payer set the date and the amount, and no business sends instructions or retries on later days.", "rests_on": "rule", "facet": "hours", "parameters": { "time_window": { "times": [ "00:00", "08:00", "18:00", "21:00" ], "timezone": "America/Sao_Paulo", "on": "calendar_day", "actor": "pix:role.payer-psp", "text": "first attempt 00:00 to 08:00 on the chosen date; at least one retry 18:00 to 21:00 if the balance was short; payer may cancel until 23:59 the day before" } }, "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "section": "arts. 12 and 14", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "art. 11-D par. unico", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-agendado", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-cobranca", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:rule.automatico-settles-between-00-and-08-with-an-evening-retry", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "IN BCB n. 513/2024 arts. 12 and 14 and Regulamento Pix art. 11-D par. unico, read 2026-09-22. The closing contrast with Pix Automatico is drawn from the two sets of articles and is [Inference] in its framing only.", "confidence": "high" }, "currency": { "effective_since": "2024-10-28", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. IN BCB n. 513/2024 art. 17 I puts arts. 12 to 14 in force on 2024-10-28.", "source_edition": "Instrucao Normativa BCB n. 513 de 30/8/2024, consolidated text version 5.0 as served on 2026-09-22, with the amendments by IN BCB n. 614/2025, n. 634/2025 and n. 743/2026 shown in place; Regulamento Pix annexed to Resolucao BCB n. 1/2020, consolidated text as served on 2026-09-22, Chapter V, Section II", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms art 12: the payer bank sends a Pix Agendado or a scheduled due date charge for settlement between 00:00 and 08:00 if balance and limit allow, notifies and retries at least once between 18:00 and 21:00 on a balance shortfall or operational failure with 21:00 the last try, and notifies on a limit shortfall; confirms art 14 that the payer may cancel such a scheduled payment up to 23:59 the day before" }, { "source": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms art 11-D par unico that account providers must let the payer schedule a due date Pix Cobranca charge for a future date" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.automatico-a-cycle-on-a-day-the-month-lacks", "id": "rule.automatico-a-cycle-on-a-day-the-month-lacks", "rail": "pix", "class": "Rule", "name": "Pix Automatico: when a cycle's day does not exist in the month", "statement": "Where a cycle would start on a date the month does not have, such as the 30th in February, the cycle starts on the last date the month does have (the 28th, or the 29th in a leap year). The due date of that cycle's charge is a separate matter that the rulebook leaves to the contract between payer and business: it may fall on the 28th, on 1 March, or on any other day of that cycle, provided the planned settlement date does not run past the cycle's end. Pix Agendado has a different, fixed rule for the same problem.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "section": "Annex IV section 4.3.1 and its footnote 105", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-automatico", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:rule.agendado-a-repeat-date-the-month-lacks-moves-to-the-1st", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Manual de Padroes para Iniciacao do Pix 2.10.0 Annex IV section 4.3.1, read 2026-09-22.", "confidence": "high" }, "currency": { "effective_since": "2025-06-16", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. The Regulamento's Pix Automatico subsection was added by Resolucao BCB n. 402 of 22/7/2024, and IN BCB n. 513/2024 art. 17 II puts the Pix Automatico procedures in force on 2025-06-16, which is used here as the date the product's rules began to bind.", "source_edition": "Manual de Padroes para Iniciacao do Pix version 2.10.0 of 2026-08-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms at Annex IV section 4.3.1 that a cycle starting on a date the month lacks starts instead on the immediately preceding existing date, that footnote 105 gives 29 February in a leap year, that the due date is left to the contract between the users, and that the settlement date may not run past the cycle end shown in the worked example" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:mandate.pix-automatico-authorisation", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.agendado-a-repeat-date-the-month-lacks-moves-to-the-1st", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.automatico-a-faulty-payment-is-refunded-within-24-hours", "id": "rule.automatico-a-faulty-payment-is-refunded-within-24-hours", "rail": "pix", "class": "Rule", "name": "Pix Automatico: the payer's bank refunds a faulty payment within 24 hours", "statement": "When a Pix Automatico payment should not have gone through, the MED ground that covers the payer's bank's own error, a missing authorisation or a departure from its terms, the payer's bank must return the whole amount to the payer from its own funds within 24 hours of the payer asking.", "rests_on": "rule", "facet": "refund", "parameters": { "time_window": { "count": 24, "unit": "hour", "from": "receipt", "actor": "pix:role.payer-psp", "text": "full refund to the payer, from the bank's own funds, within 24 hours of the payer's request" } }, "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "section": "art. 15", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.med", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-automatico", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:rule.liability-pix-automatico-the-payers-bank-pays-first", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:rule.recall-what-the-special-mechanism-is-for", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "IN BCB n. 513/2024 art. 15, read 2026-09-22, which applies Regulamento art. 41-B inciso III. The duty to pay first from own funds is already held, from the Regulamento, by pix:rule.liability-pix-automatico-the-payers-bank-pays-first; this Rule adds the 24 hour clock from a different document.", "confidence": "high" }, "currency": { "effective_since": "2025-06-16", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. The Regulamento's Pix Automatico subsection was added by Resolucao BCB n. 402 of 22/7/2024, and IN BCB n. 513/2024 art. 17 II puts the Pix Automatico procedures in force on 2025-06-16, which is used here as the date the product's rules began to bind.", "source_edition": "Instrucao Normativa BCB n. 513 de 30/8/2024, consolidated text version 5.0 as served on 2026-09-22, with the amendments by IN BCB n. 614/2025, n. 634/2025 and n. 743/2026 shown in place", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms art 15 that in the cases under Regulamento art 41-B inciso III the payer bank must return the full amount to the payer from its own funds within 24 hours of the payer's refund request" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.automatico-a-pending-request-lapses-after-30-days", "id": "rule.automatico-a-pending-request-lapses-after-30-days", "rail": "pix", "class": "Rule", "name": "Pix Automatico: a journey 1 request stays open for at most 30 days", "statement": "A request sent in journey 1 waits at the payer's bank until one of three things happens: the payer confirms or refuses it, the payee's bank withdraws it, or 30 days pass from the moment the payee's bank sent the permission details. The business may set a shorter life. Once it is withdrawn or has run out, the payer's bank must delete it. On the last day of a still pending request the payer's bank must warn the payer. A payer who refuses must say either that they do not recognise the business or that they do not want Pix Automatico for that payment, and those two answers travel back as pain.012 codes AP13 and AP14.", "rests_on": "rule", "facet": "hours", "parameters": { "time_window": { "count": 30, "unit": "calendar_day", "from": "receipt", "actor": "pix:role.payer-psp", "text": "at most 30 days from the payee's bank sending the permission details, shorter if the business says so; then the payer's bank deletes the request" } }, "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "section": "art. 3 caput and paragraphs 1 and 2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-requisitos-minimos-experiencia-usuario-7-3", "section": "chapter 15 items 06 and 09", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "section": "PAIN012.xlsx domain table, RejectReason", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-automatico", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "IN BCB n. 513/2024 art. 3, the Requisitos Minimos 7.3 chapter 15 items 06 and 09, and the pain.012 domain table in spi.5.12.1.zip, all read 2026-09-22.", "confidence": "high" }, "currency": { "effective_since": "2025-06-16", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. The Regulamento's Pix Automatico subsection was added by Resolucao BCB n. 402 of 22/7/2024, and IN BCB n. 513/2024 art. 17 II puts the Pix Automatico procedures in force on 2025-06-16, which is used here as the date the product's rules began to bind.", "source_edition": "Instrucao Normativa BCB n. 513 de 30/8/2024, consolidated text version 5.0 as served on 2026-09-22, with the amendments by IN BCB n. 614/2025, n. 634/2025 and n. 743/2026 shown in place; Requisitos Minimos para a Experiencia do Usuario version 7.3 of December 2025; its cover announces version 7.4 in force from 2027-03-01; SPI message definitions spi.5.12.1.zip (in production since 2026-06-28) and spi.5.13.1.zip (production from 2026-10-25), domain tables", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms art 3 caput and pars 1 and 2: a journey 1 request stays open until confirmation or refusal, a 30 day ceiling from the receiving bank sending the permission details that the receiving user may shorten, or the receiving bank withdrawing the request, and the payer bank must delete the request once it lapses or is withdrawn" }, { "source": "pix:src.bcb-requisitos-minimos-experiencia-usuario-7-3", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms chapter 15 item 06 that on the day a pending journey 1 request expires the payer bank must warn the payer, and item 09 that a payer refusing must indicate either not recognising the receiver or not wanting Pix Automatico for that payment" }, { "source": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms in the PAIN012.xlsx domain table that AP13 is NotRecognizedByDebtor and AP14 is RejectedByDebtor, the two reject reasons a payer refusal carries" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:mandate.pix-automatico-authorisation", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "pix:state.recurrence-created", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "pix:state.recurrence-rejected", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.automatico-a-pre-approved-credit-line-may-fund-it", "id": "rule.automatico-a-pre-approved-credit-line-may-fund-it", "rail": "pix", "class": "Rule", "name": "Pix Automatico: a pre-approved credit line may pay what the balance cannot", "statement": "A collection need not come only from the balance. Whether a pre-approved credit line, such as an overdraft, may cover a payment the available balance falls short of is one of the parameters of every authorisation, and it is the payer's call. Where the bank offers it, the setting starts switched on, and the payer may switch it off at any time, per authorisation. Nothing in the texts read changes the payment's character when credit funds it: it is still the same Pix Automatico.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "art. 11-U inciso V alinea c", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-requisitos-minimos-experiencia-usuario-7-3", "section": "chapter 15 items 02, 04, 28 and 29", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-automatico", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Regulamento Pix art. 11-U inciso V alinea c and the Requisitos Minimos 7.3 chapter 15 items 02, 04, 28 and 29, read 2026-09-22. The last sentence is [Inference] from the absence of any separate treatment.", "confidence": "high" }, "currency": { "effective_since": "2025-06-16", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. The Regulamento's Pix Automatico subsection was added by Resolucao BCB n. 402 of 22/7/2024, and IN BCB n. 513/2024 art. 17 II puts the Pix Automatico procedures in force on 2025-06-16, which is used here as the date the product's rules began to bind.", "source_edition": "Regulamento Pix annexed to Resolucao BCB n. 1/2020, consolidated text as served on 2026-09-22, Chapter V, Section II; Requisitos Minimos para a Experiencia do Usuario version 7.3 of December 2025; its cover announces version 7.4 in force from 2027-03-01", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms art 11-U inciso V alinea c that whether a pre-approved credit line may cover a shortfall against the available balance is one of the authorisation parameters, chosen by the payer" }, { "source": "pix:src.bcb-requisitos-minimos-experiencia-usuario-7-3", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms chapter 15 items 28 and 29 that credit line use starts enabled by default where the PSP offers it, and that the payer may switch it off per authorisation" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:mandate.pix-automatico-authorisation", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.automatico-a-settlement-error-allows-a-same-day-resend", "id": "rule.automatico-a-settlement-error-allows-a-same-day-resend", "rail": "pix", "class": "Rule", "name": "Pix Automatico: resending after an error in the settlement flow", "statement": "If a payment fails in the settlement flow after the payer's bank has sent it, that bank must tell the payee's bank at once, and the payee's bank must resend the instruction so the payer's bank can try again the same day. The resend must carry the same amount, is still checked against the authorisation, and is accepted only until 21:00 on the original settlement date. Where the failure was the payee's own bank rejecting the payment, resending is at that bank's discretion. This same day resend is the only case in which an instruction for the same charge may be sent on the settlement date itself.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "section": "arts. 5 par. 4 and 7 paragraphs 11 to 16", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-automatico", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "IN BCB n. 513/2024 art. 5 par. 4 and art. 7 paragraphs 11 to 16, in the wordings of IN BCB n. 614/2025, read 2026-09-22.", "confidence": "high" }, "currency": { "effective_since": "2025-06-16", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. The Regulamento's Pix Automatico subsection was added by Resolucao BCB n. 402 of 22/7/2024, and IN BCB n. 513/2024 art. 17 II puts the Pix Automatico procedures in force on 2025-06-16, which is used here as the date the product's rules began to bind.", "source_edition": "Instrucao Normativa BCB n. 513 de 30/8/2024, consolidated text version 5.0 as served on 2026-09-22, with the amendments by IN BCB n. 614/2025, n. 634/2025 and n. 743/2026 shown in place", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms art 5 par 4 that a same day resend is allowed only after an operational failure following art 7 pars 11 to 16, and confirms art 7 pars 11 to 16 in the wording of IN 614/2025: the payer bank tells the payee bank at once, the payee bank resends so the payer bank can retry the same day, the resend is checked against art 6 par 1 incisos II, III, IV and VII, accepted only until 21h on the original date, at the payee bank discretion when that bank itself rejected the payment, and must carry the same amount as the original order" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:mandate.pix-automatico-authorisation", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.automatico-a-standing-authorisation-not-a-debit-pull", "id": "rule.automatico-a-standing-authorisation-not-a-debit-pull", "rail": "pix", "class": "Rule", "name": "Pix Automatico: one authorisation, then collections the payer's bank pushes", "statement": "Pix Automatico is a Pix the payer's own bank starts from the payer's account each time the payee's bank sends it a payment instruction. What makes that possible is a single authorisation the payer gives their own bank before the first instruction arrives; after that no instruction needs the payer to authenticate again. The authorisation is also the payer's permission for the payee to keep sending instructions, it must serve one stated purpose, and it may cover several products or services from the same payee as long as they are billed together. The payee's side may be the payee's own account provider or a participant offering payment initiation, in which case the authorisation doubles as the Open Finance consent. Every collection is still an instruction the payee's bank sends and the payer's bank acts on; the authorisation never produces a payment by itself.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "art. 11-Q caput, par. 1 incisos I, II, III and VI, and par. 2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-automatico", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:rule.messages-pix-automatico-instruction-messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Regulamento Pix art. 11-Q, read 2026-09-22 in the consolidated text.", "confidence": "high" }, "currency": { "effective_since": "2025-06-16", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. The Regulamento's Pix Automatico subsection was added by Resolucao BCB n. 402 of 22/7/2024, and IN BCB n. 513/2024 art. 17 II puts the Pix Automatico procedures in force on 2025-06-16, which is used here as the date the product's rules began to bind.", "source_edition": "Regulamento Pix annexed to Resolucao BCB n. 1/2020, consolidated text as served on 2026-09-22, Chapter V, Section II", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms art 11-Q caput that the payer bank starts each Pix on periodic instructions from the receiver bank under a prior specific authorisation, par 1 I that the authorisation is given once before the first instruction with no per transaction authentication, II that it is the Open Finance consent step where the receiver provides payment initiation, III that it permits the receiver to keep sending instructions, VI that it must have a specific purpose and may cover several products billed together, and par 2 that the receiver side may be its own account provider or an initiation participant" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:mandate.pix-automatico-authorisation", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.automatico-cancelling-one-scheduled-payment", "id": "rule.automatico-cancelling-one-scheduled-payment", "rail": "pix", "class": "Rule", "name": "Pix Automatico: calling off one scheduled payment", "statement": "A single scheduled collection can be stopped without touching the authorisation. The payer's bank must cancel it when its customer asks by 23:59 on the day before the settlement date, or when the payee's bank asks by 22:00 on that day before. After those cut-offs the payment runs. On the business's side a recurring charge can be cancelled only up to the day before its first settlement attempt; after that it can only expire. A business that needs to correct a charge cancels it and issues a new one with a new transaction identifier, inside the permitted scheduling window.", "rests_on": "rule", "facet": "recall", "parameters": { "time_window": { "times": [ "22:00", "23:59" ], "timezone": "America/Sao_Paulo", "on": "calendar_day", "actor": "pix:role.payer-psp", "text": "on the day before the settlement date: 22:00 for a request from the payee's bank, 23:59 for the payer's own request" } }, "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "section": "art. 8", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-requisitos-minimos-experiencia-usuario-7-3", "section": "chapter 15 items 32 and 34", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "section": "Annex IV section 4.3.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-automatico", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:rule.messages-pix-automatico-instruction-messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "IN BCB n. 513/2024 art. 8, the Requisitos Minimos 7.3 chapter 15 items 32 and 34, and the Manual de Padroes para Iniciacao do Pix 2.10.0 Annex IV section 4.3.2, read 2026-09-22. The camt.055 and camt.029 that carry the cancellation are held by pix:rule.messages-pix-automatico-instruction-messages.", "confidence": "high" }, "currency": { "effective_since": "2025-06-16", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. The Regulamento's Pix Automatico subsection was added by Resolucao BCB n. 402 of 22/7/2024, and IN BCB n. 513/2024 art. 17 II puts the Pix Automatico procedures in force on 2025-06-16, which is used here as the date the product's rules began to bind.", "source_edition": "Instrucao Normativa BCB n. 513 de 30/8/2024, consolidated text version 5.0 as served on 2026-09-22, with the amendments by IN BCB n. 614/2025, n. 634/2025 and n. 743/2026 shown in place; Requisitos Minimos para a Experiencia do Usuario version 7.3 of December 2025; its cover announces version 7.4 in force from 2027-03-01; Manual de Padroes para Iniciacao do Pix version 2.10.0 of 2026-08-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms art 8: the payer bank must cancel a scheduled payment when its customer asks by 23:59 the day before settlement or the receiving bank asks by 22:00 that day before" }, { "source": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms at Annex IV section 4.3.2 that a recurring charge can be cancelled by the receiving user only up to the day before the first settlement attempt, that after that cutoff it can only expire, and that correcting a charge means cancelling it and creating a new one with a new txid inside the permitted scheduling window" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:mandate.pix-automatico-authorisation", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.automatico-cancelling-the-authorisation-stops-what-is-scheduled", "id": "rule.automatico-cancelling-the-authorisation-stops-what-is-scheduled", "rail": "pix", "class": "Rule", "name": "Pix Automatico: what a cancellation does to payments already scheduled", "statement": "Cancelling the authorisation takes every payment already scheduled under it with it, except the one due that same day. If the payer cancels, the bank drops every scheduled payment dated after the day of cancellation. If the business withdraws, the payer's bank drops every scheduled payment dated after the day it hears of it, and if that news arrives between 22:00 and 23:59 the payment due the next day survives too. The payer's app must say before the payer confirms that the cancellation is final and that only today's payment will still run, and when it is the business that cancelled, the bank must tell the payer which scheduled payments go and that no new ones will be scheduled.", "rests_on": "rule", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "section": "art. 9 caput and paragraphs 1, 2 and 3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-requisitos-minimos-experiencia-usuario-7-3", "section": "chapter 15 items 27 and 52", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-automatico", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "IN BCB n. 513/2024 art. 9 and the Requisitos Minimos 7.3 chapter 15 items 27 and 52, read 2026-09-22.", "confidence": "high" }, "currency": { "effective_since": "2025-06-16", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. The Regulamento's Pix Automatico subsection was added by Resolucao BCB n. 402 of 22/7/2024, and IN BCB n. 513/2024 art. 17 II puts the Pix Automatico procedures in force on 2025-06-16, which is used here as the date the product's rules began to bind.", "source_edition": "Instrucao Normativa BCB n. 513 de 30/8/2024, consolidated text version 5.0 as served on 2026-09-22, with the amendments by IN BCB n. 614/2025, n. 634/2025 and n. 743/2026 shown in place; Requisitos Minimos para a Experiencia do Usuario version 7.3 of December 2025; its cover announces version 7.4 in force from 2027-03-01", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms art 9 caput and pars 1 to 3: cancelling drops every payment scheduled after the cancellation day, a payer cancellation drops payments dated after the cancellation day, a business cancellation drops payments dated after the payer bank hears of it, and a 22:00 to 23:59 notice still protects the next day's payment" }, { "source": "pix:src.bcb-requisitos-minimos-experiencia-usuario-7-3", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms chapter 15 item 27 that the payer confirmation screen must say the cancellation cannot be undone and that only a payment scheduled for today survives, and item 52 that on a business cancellation the payer bank must notify the payer which scheduled payments are dropped and that no new ones will be scheduled" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:mandate.pix-automatico-authorisation", "type": "revoked_via", "status": "draft", "effective_status": "draft" }, { "from": "pix:state.recurrence-cancelled", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.automatico-either-side-may-cancel-the-authorisation", "id": "rule.automatico-either-side-may-cancel-the-authorisation", "rail": "pix", "class": "Rule", "name": "Pix Automatico: cancelling the authorisation, and the recorded reasons", "statement": "Either end user or either bank may cancel a recurrence on its own, and each bank must act on its customer's request and pass the cancellation to the other bank with a pain.011, answered by a pain.012. When the business asks for its permission to be withdrawn, the payer's bank must cancel the authorisation. The pain.011 carries who asked and one of eleven proprietary reasons, among them the payer's own request, the business's request, a closed account, a business that has shut down, the payer's death (DCSD), suspected fraud and a court order. A cancelled authorisation cannot be reinstated; a new one is needed.", "rests_on": "rule", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "art. 11-Q par. 1 incisos IV and V", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "section": "Annex V section 3.3 and Annex IV section 2.1.6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "section": "PAIN011.xlsx domain table, CancellationReason Proprietary", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-requisitos-minimos-experiencia-usuario-7-3", "section": "chapter 15 item 27", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-automatico", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:rule.messages-pix-automatico-authorization-messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Regulamento Pix art. 11-Q par. 1, the Manual de Padroes para Iniciacao do Pix 2.10.0 Annex V section 3.3 and Annex IV section 2.1.6, the pain.011 domain table in spi.5.12.1.zip and spi.5.13.1.zip (unchanged between them), and the Requisitos Minimos 7.3 chapter 15 item 27, all read 2026-09-22. The full list is pix:codeset.pain011-cancellation-reasons.", "confidence": "high" }, "currency": { "effective_since": "2025-06-16", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. The Regulamento's Pix Automatico subsection was added by Resolucao BCB n. 402 of 22/7/2024, and IN BCB n. 513/2024 art. 17 II puts the Pix Automatico procedures in force on 2025-06-16, which is used here as the date the product's rules began to bind.", "source_edition": "Regulamento Pix annexed to Resolucao BCB n. 1/2020, consolidated text as served on 2026-09-22, Chapter V, Section II; Manual de Padroes para Iniciacao do Pix version 2.10.0 of 2026-08-19; SPI message definitions spi.5.12.1.zip (in production since 2026-06-28) and spi.5.13.1.zip (production from 2026-10-25), domain tables; Requisitos Minimos para a Experiencia do Usuario version 7.3 of December 2025; its cover announces version 7.4 in force from 2027-03-01", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms art 11-Q par 1 IV that the payer may cancel or, where allowed, alter the authorisation unilaterally at any time, and par 1 V that the payer bank must cancel the authorisation when the receiving bank reports the receiving user withdrew its permission" }, { "source": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms at Annex V section 3.3 that either end user, through either bank, may unilaterally request cancellation and the banks must act on it and pass the information to the other bank via pain.011, that pain.012 answers all Pix Automatico authorisation and cancellation flows per Annex V section 3.2, and confirms at Annex IV section 2.1.6 and the Annex I section 5.1 state list that a cancelled recurrence has no return path" }, { "source": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms in the PAIN011.xlsx domain table that CancellationReason Proprietary lists eleven codes: ACCL, CPCL, DCSD, ERSL, FRUD, NRES, OTHS, PCFD, SJUD, SLCR and SLDB, including the payer's own request (SLDB), the business's request (SLCR), a closed account (ACCL), a business shut down (CPCL), the payer's death (DCSD), suspected fraud (FRUD) and a court order (SJUD)" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:codeset.pain011-cancellation-reasons", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:mandate.pix-automatico-authorisation", "type": "revoked_via", "status": "draft", "effective_status": "draft" }, { "from": "pix:state.recurrence-cancelled", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.automatico-five-recurrence-periods", "id": "rule.automatico-five-recurrence-periods", "rail": "pix", "class": "Rule", "name": "Pix Automatico: weekly, monthly, quarterly, half-yearly or yearly, and one charge per cycle", "statement": "The recurrence period of an authorisation is chosen from a closed list of five: weekly, monthly, quarterly, half-yearly and yearly. The messages carry them as WEEK, MNTH, QURT, MIAN and YEAR. Each period defines a cycle whose start and end follow from the period and the start date of the recurrence, and only one charge may be scheduled per cycle; a second one in the same cycle is refused unless it is a resend after a settlement error or a retry after the due date.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "section": "arts. 2 and 5 par. 3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "section": "Annex IV section 4.3.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "section": "PAIN011.xlsx and PAIN012.xlsx domain tables, Frequency Type", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-automatico", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "IN BCB n. 513/2024 arts. 2 and 5 par. 3, the Manual de Padroes para Iniciacao do Pix 2.10.0 Annex IV section 4.3.1, and the pain.011 and pain.012 domain tables in spi.5.12.1.zip, all read 2026-09-22.", "confidence": "high" }, "currency": { "effective_since": "2025-06-16", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. The Regulamento's Pix Automatico subsection was added by Resolucao BCB n. 402 of 22/7/2024, and IN BCB n. 513/2024 art. 17 II puts the Pix Automatico procedures in force on 2025-06-16, which is used here as the date the product's rules began to bind.", "source_edition": "Instrucao Normativa BCB n. 513 de 30/8/2024, consolidated text version 5.0 as served on 2026-09-22, with the amendments by IN BCB n. 614/2025, n. 634/2025 and n. 743/2026 shown in place; Manual de Padroes para Iniciacao do Pix version 2.10.0 of 2026-08-19; SPI message definitions spi.5.12.1.zip (in production since 2026-06-28) and spi.5.13.1.zip (production from 2026-10-25), domain tables", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms art 2 lists exactly five recurrence periods, weekly, monthly, quarterly, half-yearly and yearly, and art 5 par 3 defines a cycle from the periodicity and the recurrence start date" }, { "source": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms at Annex IV section 4.3.1 that only one charge may be scheduled per cycle, rejecting new attempts except a resend after a settlement error (RIFL) or a retry after the due date (NTAG), and that WEEK, MNTH, QURT, MIAN and YEAR are the frequency type domain values read in the PAIN011 and PAIN012 message spreadsheets" }, { "source": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms in the PAIN011.xlsx and PAIN012.xlsx domain tables that WEEK, MNTH, QURT, MIAN and YEAR are the five frequency type codes used for the recurrence period" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:mandate.pix-automatico-authorisation", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.automatico-four-journeys-to-an-authorisation", "id": "rule.automatico-four-journeys-to-an-authorisation", "rail": "pix", "class": "Rule", "name": "Pix Automatico: the four ways an authorisation is given", "statement": "There are four journeys, numbered 1 to 4 in the manuals and carried as AUT1 to AUT4 on the confirming pain.012. In journey 1 the payer agrees terms with the business directly, outside Pix, and the business's bank sends the request (a pain.009) to the payer's bank, where the payer confirms it under Pending authorisations. In journey 2 the payer scans a composite QR code that carries only the recurrence terms. In journey 3 the QR code carries the terms and an immediate first charge, and paying that charge and authorising happen together. In journey 4 the payer pays an ordinary charge by QR code and is then offered Pix Automatico for the payments after it. A fifth route runs under the Open Finance rules. Every account provider serving payers must support journeys 1 to 4 for all its payers, while a payee's bank chooses which of them it offers its business customers. The payer's bank must make the journey 4 offer even when the payer chose to schedule the charge rather than pay it at once.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "arts. 11-Q par. 1 incisos VII and VIII, 11-S par. 3 and 11-T par. 6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "section": "art. 4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "section": "sections 2.4.3, 2.8 and 6.3, and Annex IV section 2.1.7", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "section": "PAIN012.xlsx domain table, MandateProcessingType", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-automatico", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Regulamento Pix arts. 11-Q, 11-S and 11-T, IN BCB n. 513/2024 art. 4, the Manual de Padroes para Iniciacao do Pix 2.10.0 sections 2.4.3, 2.8, 6.3 and Annex IV 2.1.7, and the pain.012 domain table in spi.5.12.1.zip, all read 2026-09-22. The numbering 1 to 4 is the manuals'; the Regulamento letters the same journeys a to d.", "confidence": "high" }, "currency": { "effective_since": "2025-06-16", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. The Regulamento's Pix Automatico subsection was added by Resolucao BCB n. 402 of 22/7/2024, and IN BCB n. 513/2024 art. 17 II puts the Pix Automatico procedures in force on 2025-06-16, which is used here as the date the product's rules began to bind.", "source_edition": "Regulamento Pix annexed to Resolucao BCB n. 1/2020, consolidated text as served on 2026-09-22, Chapter V, Section II; Instrucao Normativa BCB n. 513 de 30/8/2024, consolidated text version 5.0 as served on 2026-09-22, with the amendments by IN BCB n. 614/2025, n. 634/2025 and n. 743/2026 shown in place; Manual de Padroes para Iniciacao do Pix version 2.10.0 of 2026-08-19; SPI message definitions spi.5.12.1.zip (in production since 2026-06-28) and spi.5.13.1.zip (production from 2026-10-25), domain tables", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms art 11-Q par 1 VII incisos a to d list the four journeys (direct request and confirmation, QR code with only recurrence terms, QR code with recurrence and an immediate first payment, and an offer after paying an ordinary charge), inciso VIII the fifth Open Finance route, art 11-S par 3 that the account provider must offer journeys a to d to all its payers, and art 11-T par 6 that the receiver bank chooses which of them to offer its business customers" }, { "source": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms at Annex V section 3.2 that the confirming pain.012 carries AUT1, AUT2, AUT3 or AUT4 to mark which of the four journeys was used, and at Annex IV section 4.4 that the composite QR code composition differs for journeys 2, 3 and 4 as the record describes" }, { "source": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms art 4 that the payer bank must make the journey 4 (art 11-Q par 1 VII d) offer even where the payer scheduled rather than paid the QR code charge at once" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:mandate.pix-automatico-authorisation", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "pix:state.recurrence-created", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.automatico-instructions-go-2-to-10-days-ahead", "id": "rule.automatico-instructions-go-2-to-10-days-ahead", "rail": "pix", "class": "Rule", "name": "Pix Automatico: when a collection instruction may be sent", "statement": "The payee's bank sends each cycle's instruction, carrying the charge's details, as a rule between 10 and 2 calendar days before the planned settlement date. The payer's bank refuses an instruction that arrives more than 10 days ahead (pain.014 FCD1) or less than 2 days ahead (FCD2). Late is allowed only as an exception, where the business had trouble producing the instruction: there must still be 2 calendar days between scheduling and settlement, the settlement date must fall before the next cycle starts (or before the recurrence ends, for the last cycle), and the business may charge no late fees for the delay it caused. The payee's bank must send an instruction only if it matches the authorisation, never before the authorisation is confirmed, and must identify the business by its CNPJ as the Federal Revenue registers it.", "rests_on": "rule", "facet": "hours", "parameters": { "time_window": { "count": 2, "unit": "calendar_day", "from": "settlement_date", "actor": "pix:role.receiver-psp", "text": "the instruction reaches the payer's bank no later than 2 calendar days and, as a rule, no earlier than 10 calendar days before the planned settlement date" } }, "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "section": "art. 5 paragraphs 1, 2, 7, 8 and 10", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "section": "PAIN014.xlsx domain table, FCD1 and FCD2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-automatico", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "IN BCB n. 513/2024 art. 5 and the pain.014 domain table in spi.5.12.1.zip, read 2026-09-22.", "confidence": "high" }, "currency": { "effective_since": "2025-06-16", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. The Regulamento's Pix Automatico subsection was added by Resolucao BCB n. 402 of 22/7/2024, and IN BCB n. 513/2024 art. 17 II puts the Pix Automatico procedures in force on 2025-06-16, which is used here as the date the product's rules began to bind.", "source_edition": "Instrucao Normativa BCB n. 513 de 30/8/2024, consolidated text version 5.0 as served on 2026-09-22, with the amendments by IN BCB n. 614/2025, n. 634/2025 and n. 743/2026 shown in place; SPI message definitions spi.5.12.1.zip (in production since 2026-06-28) and spi.5.13.1.zip (production from 2026-10-25), domain tables", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms art 5 pars 1, 2, 7 and 8: instructions go out 2 to 10 calendar days ahead as a rule, a late exception only where the receiving user had trouble generating the instruction, no late fees for a delay the receiving user caused, sending only instructions that match the authorisation, and never before confirmation" }, { "source": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms in the PAIN014.xlsx domain table that FCD1 and FCD2 are the two FailureToComplyBusinessRuleDeadline reject reasons for an instruction sent outside the 2 to 10 day window" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:mandate.pix-automatico-authorisation", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.automatico-journey-3-needs-the-first-payment-to-settle", "id": "rule.automatico-journey-3-needs-the-first-payment-to-settle", "rail": "pix", "class": "Rule", "name": "Pix Automatico: in journey 3 the first payment is a condition of the authorisation", "statement": "Only journey 3 ties the authorisation to a payment. There the payer confirms an immediate first payment and the authorisation in one step, the app must show that the first payment settling is a condition of the authorisation, and if that payment does not go through for any reason the authorisation is not concluded and the payer must be told at once. The payee's bank refuses such an authorisation with pain.012 code AP08 when it cannot find the first payment. If the payment settles and the authorisation still fails, the payer gets the receipt and is told to contact the business to arrange later payments. In journeys 1, 2 and 4 the authorisation is given before any collection and no first payment activates it.", "rests_on": "rule", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-requisitos-minimos-experiencia-usuario-7-3", "section": "chapter 15 items 20, 22 and 23", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "art. 11-Q par. 1 incisos I and VII alinea c", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "section": "PAIN012.xlsx domain table, RejectReason AP08", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "section": "section 6.3.3", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-automatico", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The Requisitos Minimos 7.3 chapter 15 items 20, 22 and 23, Regulamento Pix art. 11-Q, the pain.012 domain table in spi.5.12.1.zip, and the Manual de Padroes para Iniciacao do Pix 2.10.0 section 6.3.3, all read 2026-09-22.", "confidence": "high" }, "currency": { "effective_since": "2025-06-16", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. The Regulamento's Pix Automatico subsection was added by Resolucao BCB n. 402 of 22/7/2024, and IN BCB n. 513/2024 art. 17 II puts the Pix Automatico procedures in force on 2025-06-16, which is used here as the date the product's rules began to bind.", "source_edition": "Requisitos Minimos para a Experiencia do Usuario version 7.3 of December 2025; its cover announces version 7.4 in force from 2027-03-01; Regulamento Pix annexed to Resolucao BCB n. 1/2020, consolidated text as served on 2026-09-22, Chapter V, Section II; SPI message definitions spi.5.12.1.zip (in production since 2026-06-28) and spi.5.13.1.zip (production from 2026-10-25), domain tables; Manual de Padroes para Iniciacao do Pix version 2.10.0 of 2026-08-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-requisitos-minimos-experiencia-usuario-7-3", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms chapter 15 items 19 to 23: in journey 3 the immediate first payment and the authorisation are confirmed together, an unsuccessful first payment leaves the authorisation not concluded, and the payer must be told at once whether the first payment settled but the authorisation failed, or the first payment itself did not go through" }, { "source": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms in the PAIN012.xlsx domain table that AP08 (AssociatedInstantPaymentNotSettled) refuses a journey 3 authorisation when the associated immediate first payment was not identified, and is valid only for journey 3" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:mandate.pix-automatico-authorisation", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.automatico-retries-on-later-days", "id": "rule.automatico-retries-on-later-days", "rail": "pix", "class": "Rule", "name": "Pix Automatico: retries on later days, at most 3 within 7 days", "statement": "If the payment did not go on the settlement date for want of balance, limit or through an operational failure, the business may try again on later days, but only if the authorisation provides for it; the business picks the policy when it creates the recurrence, either no later retries or up to three. Each retry is a new instruction the payee's bank sends by 23:59 on the day before the retry date, for the same amount as the original, on no more than three different dates, within 7 calendar days of the original settlement date and never on or after the start of the next cycle (or the end of the recurrence, for the last one). On each retry date the payer's bank runs the same 00:00 to 08:00 and 18:00 to 21:00 attempts as on the original date. The payer's bank refuses a retry the recurrence does not allow (pain.014 IRNT), a fourth retry (QUNT) and one from the eighth day on (DTNT).", "rests_on": "rule", "facet": "hours", "parameters": { "time_window": { "count": 7, "unit": "calendar_day", "from": "settlement_date", "actor": "pix:role.receiver-psp", "text": "up to 3 retries on different dates within 7 calendar days of the original settlement date, only if the authorisation allows it, and never into the next cycle" } }, "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "section": "art. 7 paragraphs 5 to 10", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "art. 11-U inciso VI", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "section": "Annex IV section 2.1.5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "section": "PAIN014.xlsx domain table, IRNT, QUNT and DTNT", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-automatico", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "IN BCB n. 513/2024 art. 7 paragraphs 5 to 10, Regulamento Pix art. 11-U inciso VI, the Manual de Padroes para Iniciacao do Pix 2.10.0 Annex IV section 2.1.5 (the politicaRetentativa options NAO_PERMITE and PERMITE_3R_7D), and the pain.014 domain table in spi.5.12.1.zip, all read 2026-09-22.", "confidence": "high" }, "currency": { "effective_since": "2025-06-16", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. The Regulamento's Pix Automatico subsection was added by Resolucao BCB n. 402 of 22/7/2024, and IN BCB n. 513/2024 art. 17 II puts the Pix Automatico procedures in force on 2025-06-16, which is used here as the date the product's rules began to bind.", "source_edition": "Instrucao Normativa BCB n. 513 de 30/8/2024, consolidated text version 5.0 as served on 2026-09-22, with the amendments by IN BCB n. 614/2025, n. 634/2025 and n. 743/2026 shown in place; Regulamento Pix annexed to Resolucao BCB n. 1/2020, consolidated text as served on 2026-09-22, Chapter V, Section II; Manual de Padroes para Iniciacao do Pix version 2.10.0 of 2026-08-19; SPI message definitions spi.5.12.1.zip (in production since 2026-06-28) and spi.5.13.1.zip (production from 2026-10-25), domain tables", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms art 7 pars 5 to 10: retries after want of balance, limit or operational failure run only if the authorisation allows them, up to 3 within 7 calendar days of the original settlement date, each retry sent by 23:59 the day before, for the same amount, and never into the next cycle" }, { "source": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms at Annex IV section 2.1.5 (politicaRetentativa) and section 4.1.4 that the business chooses between NAO_PERMITE and PERMITE_3R_7D when creating the recurrence, that the payer may only accept or refuse the whole recurrence and not this one setting on its own, and confirms the current rule allows at most 3 new attempts on different days within 7 calendar days after the original settlement date" }, { "source": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms in the PAIN014.xlsx domain table that IRNT is a retry the recurrence does not allow, QUNT is a retry count over the business rule limit, and DTNT is a retry outside the day limit the business rule sets" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:mandate.pix-automatico-authorisation", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.automatico-settlement-date-is-the-due-date", "id": "rule.automatico-settlement-date-is-the-due-date", "rail": "pix", "class": "Rule", "name": "Pix Automatico: the settlement date is the due date, and payments run on any day", "statement": "The settlement date in an instruction must be the charge's due date. If the due date is not a business day the business may choose to settle on the next business day instead; it is not obliged to, and payments may fall on any day, business day or not.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "section": "art. 5 paragraphs 5 and 6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-requisitos-minimos-experiencia-usuario-7-3", "section": "chapter 15 item 04", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-automatico", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "IN BCB n. 513/2024 art. 5 paragraphs 5 and 6 and the Requisitos Minimos 7.3 chapter 15 item 04, read 2026-09-22.", "confidence": "high" }, "currency": { "effective_since": "2025-06-16", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. The Regulamento's Pix Automatico subsection was added by Resolucao BCB n. 402 of 22/7/2024, and IN BCB n. 513/2024 art. 17 II puts the Pix Automatico procedures in force on 2025-06-16, which is used here as the date the product's rules began to bind.", "source_edition": "Instrucao Normativa BCB n. 513 de 30/8/2024, consolidated text version 5.0 as served on 2026-09-22, with the amendments by IN BCB n. 614/2025, n. 634/2025 and n. 743/2026 shown in place; Requisitos Minimos para a Experiencia do Usuario version 7.3 of December 2025; its cover announces version 7.4 in force from 2027-03-01", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms art 5 par 5 that the settlement date must be the charge due date and par 6 that the receiving user may, at its own discretion, move a non business day due date to the next business day" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:mandate.pix-automatico-authorisation", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.automatico-settles-between-00-and-08-with-an-evening-retry", "id": "rule.automatico-settles-between-00-and-08-with-an-evening-retry", "rail": "pix", "class": "Rule", "name": "Pix Automatico: the settlement window on the day and the same day retry", "statement": "On the settlement date the payer's bank sends the payment for settlement between 00:00 and 08:00, provided the account holds enough money and the payer's Pix Automatico limit has room. If it cannot, for want of balance or of limit, or because of an operational failure, it must tell the payer the payment did not go and try at least once more between 18:00 and 21:00 the same day. It may try more often, but the last try must be by 21:00. If the last try fails the payer is told again, and told to pay by other means. The funds test is made on the day and not when the payment is scheduled, so a collection is never refused at scheduling for want of funds.", "rests_on": "rule", "facet": "hours", "parameters": { "time_window": { "times": [ "00:00", "08:00", "18:00", "21:00" ], "timezone": "America/Sao_Paulo", "on": "calendar_day", "actor": "pix:role.payer-psp", "text": "first attempt between 00:00 and 08:00 on the settlement date; at least one more between 18:00 and 21:00 the same day; none after 21:00" } }, "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "section": "art. 7 caput and paragraphs 1 to 4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-requisitos-minimos-experiencia-usuario-7-3", "section": "chapter 15 items 04, 48 and 49", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-automatico", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "IN BCB n. 513/2024 art. 7 and the Requisitos Minimos 7.3 chapter 15 items 04, 48 and 49, read 2026-09-22. The closing sentence reads the absence of any funds code in the pain.014 domain table of spi.5.12.1.zip against art. 7 and is [Inference].", "confidence": "high" }, "currency": { "effective_since": "2025-06-16", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. The Regulamento's Pix Automatico subsection was added by Resolucao BCB n. 402 of 22/7/2024, and IN BCB n. 513/2024 art. 17 II puts the Pix Automatico procedures in force on 2025-06-16, which is used here as the date the product's rules began to bind.", "source_edition": "Instrucao Normativa BCB n. 513 de 30/8/2024, consolidated text version 5.0 as served on 2026-09-22, with the amendments by IN BCB n. 614/2025, n. 634/2025 and n. 743/2026 shown in place; Requisitos Minimos para a Experiencia do Usuario version 7.3 of December 2025; its cover announces version 7.4 in force from 2027-03-01", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms art 7 caput and pars 1 to 4: the payer bank sends the payment between 00:00 and 08:00 on the settlement date, retries at least once between 18:00 and 21:00 if balance, limit or an operational failure prevents it, may try more often but no later than 21:00, and must notify the payer before and after the retry window" }, { "source": "pix:src.bcb-requisitos-minimos-experiencia-usuario-7-3", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms chapter 15 item 48 that after the last settlement attempt still failing for want of balance or daily limit the payer must be notified that the payment could not be made, and item 49 the same for an operational failure on the last attempt, telling the payer to pay by other means" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:mandate.pix-automatico-authorisation", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.agendado-and-scheduled-charges-settle-00-to-08-with-an-evening-retry", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.automatico-the-pacs008-is-marked-auto", "id": "rule.automatico-the-pacs008-is-marked-auto", "rail": "pix", "class": "Rule", "name": "Pix Automatico: how the settlement message identifies it", "statement": "The pacs.008 for a Pix Automatico payment must carry AUTO in its initiation form field, including when a payment initiator produced the instruction. Where the instruction came from a payment initiator, the receiver's reconciliation identifier on the pacs.008 is left empty (before IN BCB n. 743/2026 it was filled with zeros where no pain.013 was used).", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "section": "art. 7 paragraphs 17 and 18", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-automatico", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "IN BCB n. 513/2024 art. 7 paragraphs 17 and 18, par. 18 in the wording of IN BCB n. 743/2026, read 2026-09-22. The date IN 743 took effect was not read and is [Unverified].", "confidence": "medium" }, "currency": { "effective_since": "2025-06-16", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. The Regulamento's Pix Automatico subsection was added by Resolucao BCB n. 402 of 22/7/2024, and IN BCB n. 513/2024 art. 17 II puts the Pix Automatico procedures in force on 2025-06-16, which is used here as the date the product's rules began to bind.", "source_edition": "Instrucao Normativa BCB n. 513 de 30/8/2024, consolidated text version 5.0 as served on 2026-09-22, with the amendments by IN BCB n. 614/2025, n. 634/2025 and n. 743/2026 shown in place", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms art 7 par 17 that the pacs.008 formaDeIniciacao field must carry AUTO, including when a payment initiator generated the instruction, and confirms par 18 in the wording of IN 743/2026 that the reconciliation identifier field is left blank when a payment initiator generated the instruction" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.automatico-the-payer-sets-the-maximum-the-business-sets-its-floor", "id": "rule.automatico-the-payer-sets-the-maximum-the-business-sets-its-floor", "rail": "pix", "class": "Rule", "name": "Pix Automatico: who fixes the ceiling on a variable authorisation", "statement": "On an authorisation whose amounts vary, the maximum per payment is the payer's to set, and it is optional: by default no maximum is set. The business may set a floor under that maximum, and the payer's bank must tell the payer what it is and accept no maximum below it. On an authorisation with a fixed amount there is no maximum to set; a charge for any other amount is refused. A charge above the payer's maximum is not scheduled, and the payer's bank must tell the payer so; it may add that raising the maximum and contacting the business could still save the payment in that cycle.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "art. 11-U inciso V alinea b", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-requisitos-minimos-experiencia-usuario-7-3", "section": "chapter 15 items 16, 28, 53 and 58", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "section": "art. 6 par. 1 incisos I and II", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-automatico", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:rule.limits-the-user-can-drive-the-limit-in-both-directions", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Regulamento Pix art. 11-U inciso V alinea b, the Requisitos Minimos 7.3 chapter 15 items 16, 28, 53 and 58, and IN BCB n. 513/2024 art. 6 par. 1, all read 2026-09-22. The product limit a payer sets for Pix Automatico as a whole is a separate control held by pix:rule.limits-the-user-can-drive-the-limit-in-both-directions.", "confidence": "high" }, "currency": { "effective_since": "2025-06-16", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. The Regulamento's Pix Automatico subsection was added by Resolucao BCB n. 402 of 22/7/2024, and IN BCB n. 513/2024 art. 17 II puts the Pix Automatico procedures in force on 2025-06-16, which is used here as the date the product's rules began to bind.", "source_edition": "Regulamento Pix annexed to Resolucao BCB n. 1/2020, consolidated text as served on 2026-09-22, Chapter V, Section II; Requisitos Minimos para a Experiencia do Usuario version 7.3 of December 2025; its cover announces version 7.4 in force from 2027-03-01; Instrucao Normativa BCB n. 513 de 30/8/2024, consolidated text version 5.0 as served on 2026-09-22, with the amendments by IN BCB n. 614/2025, n. 634/2025 and n. 743/2026 shown in place", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-requisitos-minimos-experiencia-usuario-7-3", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms chapter 15 item 16 that on a variable authorisation the payer may optionally set a maximum, that a business-set floor must be told to the payer and no maximum below it accepted, and that a charge over the maximum is not scheduled and the payer is notified" }, { "source": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms art 6 par 1 incisos I and II that the payer bank refuses to schedule an amount above the payer's set maximum on a variable authorisation, or different from the fixed amount on a fixed authorisation" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:mandate.pix-automatico-authorisation", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.automatico-the-payers-bank-schedules-within-2-hours-or-refuses", "id": "rule.automatico-the-payers-bank-schedules-within-2-hours-or-refuses", "rail": "pix", "class": "Rule", "name": "Pix Automatico: the payer's bank schedules within two hours or refuses", "statement": "The payer's bank has two hours from receiving an instruction to schedule the payment it describes, and must refuse to schedule it instead where it does not fit the authorisation: an amount above the payer's maximum or different from a fixed amount, a date that does not fit the authorisation's date and period, a different business, a breach of the sending windows, no authorisation in force, or any other discrepancy that stands in the way. The refusal travels back on the pain.014. The business may then have its bank send a corrected instruction, up to 2 days before the planned settlement date.", "rests_on": "rule", "facet": "liability", "parameters": { "time_window": { "count": 2, "unit": "hour", "from": "receipt", "actor": "pix:role.payer-psp", "text": "schedule, or refuse, within two hours of receiving the payment instruction" } }, "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "section": "art. 6 caput and paragraphs 1 and 2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "section": "PAIN014.xlsx domain table, StatusReasonInformation", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-automatico", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:rule.liability-the-duty-to-reject-on-both-sides", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "IN BCB n. 513/2024 art. 6 (par. 1 inciso V as worded by IN BCB n. 743/2026, par. 2 as worded by IN BCB n. 614/2025) and the pain.014 domain table in spi.5.12.1.zip, read 2026-09-22. The general duty to refuse a Pix Automatico payment that departs from its terms is pix:rule.liability-the-duty-to-reject-on-both-sides, which cites Regulamento arts. 38 and 39; this Rule is the instruction-level detail from a different document.", "confidence": "high" }, "currency": { "effective_since": "2025-06-16", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. The Regulamento's Pix Automatico subsection was added by Resolucao BCB n. 402 of 22/7/2024, and IN BCB n. 513/2024 art. 17 II puts the Pix Automatico procedures in force on 2025-06-16, which is used here as the date the product's rules began to bind.", "source_edition": "Instrucao Normativa BCB n. 513 de 30/8/2024, consolidated text version 5.0 as served on 2026-09-22, with the amendments by IN BCB n. 614/2025, n. 634/2025 and n. 743/2026 shown in place; SPI message definitions spi.5.12.1.zip (in production since 2026-06-28) and spi.5.13.1.zip (production from 2026-10-25), domain tables", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms art 6 caput and pars 1 and 2: the payer bank schedules within 2 hours of receiving the instruction, refuses where the amount, date, business or authorisation status does not match, or another blocking discrepancy exists, and the receiving bank may send a corrected instruction up to 2 days before the planned settlement date" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:codeset.pain014-instruction-errors-from-2026", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:codeset.pain014-instruction-errors", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:mandate.pix-automatico-authorisation", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "pix:state.recurrence-approved", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.automatico-three-refusal-families-and-who-raises-them", "id": "rule.automatico-three-refusal-families-and-who-raises-them", "rail": "pix", "class": "Rule", "name": "Pix Automatico: the three places a collection can be refused, and who refuses", "statement": "Refusals fall in three families, each on its own message with its own code list, and each code in the domain tables names the side that fills it. The authorisation is refused on the pain.012 (27 reasons in catalog 5.12.1): mostly by the payer's bank (account not found, closed or blocked, salary account, payer does not recognise the business or declines), some by the payee's bank (request expired, first payment not found in journey 3), and four by the SPI. The instruction is refused on the pain.014 (25 errors in 5.12.1): all but five by the payer's bank (amount over the maximum or not the fixed amount, wrong business or payer, bad date, too early or too late, no confirmed recurrence, retry rules broken), the other five by the SPI. The payment itself is refused on the pacs.002 like any Pix, where the receiving bank has UPAY for no valid recurrence and CN01 for one already cancelled. Each list has a catch-all to be used only when no specific code fits: GRER on pain.014, CH16 on pain.012, and OTHS for cancellations. A shortfall of balance or limit on the day is not a refusal code at all; it is a failed attempt the payer is notified of. From catalog 5.13.1, in production on 2026-10-25, the SPI-raised codes leave both lists (pain.012 goes to 23, pain.014 to 20).", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "section": "PAIN012.xlsx and PAIN014.xlsx domain tables in 5.12.1 and 5.13.1", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "section": "arts. 6 par. 1 and 7 par. 1", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-automatico", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:rule.messages-pix-automatico-authorization-messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:rule.messages-pix-automatico-instruction-messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The pain.012 and pain.014 domain tables in spi.5.12.1.zip and spi.5.13.1.zip, read 2026-09-22, which give each code and the side that fills it; IN BCB n. 513/2024 arts. 6 and 7 for why funds are not a refusal code. UPAY and CN01 are the pix-reject rail's records and are not restated here. The full lists are pix:codeset.pain012-authorisation-rejection-reasons and pix:codeset.pain014-instruction-errors.", "confidence": "high" }, "currency": { "effective_since": "2026-06-28", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. effective_since is the production date of catalog 5.12.1, the version whose counts are given.", "source_edition": "SPI message definitions spi.5.12.1.zip (in production since 2026-06-28) and spi.5.13.1.zip (production from 2026-10-25), domain tables; Instrucao Normativa BCB n. 513 de 30/8/2024, consolidated text version 5.0 as served on 2026-09-22, with the amendments by IN BCB n. 614/2025, n. 634/2025 and n. 743/2026 shown in place", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "pix:codeset.pain012-authorisation-rejection-reasons-from-2026", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:codeset.pain012-authorisation-rejection-reasons", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:codeset.pain014-instruction-errors-from-2026", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:codeset.pain014-instruction-errors", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:mandate.pix-automatico-authorisation", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.automatico-what-an-authorisation-must-state", "id": "rule.automatico-what-an-authorisation-must-state", "rail": "pix", "class": "Rule", "name": "Pix Automatico: the parameters every authorisation carries", "statement": "At the least, an authorisation names the business allowed to send instructions, states the recurrence period and the planned date of the first payment, says how long it lasts if it has an end date at all (an authorisation without one runs until cancelled), and records two choices of the payer's: whether to cap each payment at a maximum, and whether a pre-approved credit line may cover a payment the balance cannot. Before confirming, the payer's app must also show the payer and debtor, the object of the payment and its contract or customer reference, a fixed amount where there is one, and the business's retry policy for later days, with a warning that paying after the due date may bring interest and a fine on the next charge.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "art. 11-U caput inciso V alineas a to f", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-requisitos-minimos-experiencia-usuario-7-3", "section": "chapter 15 items 16 and 25", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-automatico", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Regulamento Pix art. 11-U inciso V and the Requisitos Minimos 7.3 chapter 15 items 16 and 26, read 2026-09-22.", "confidence": "high" }, "currency": { "effective_since": "2025-06-16", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. The Regulamento's Pix Automatico subsection was added by Resolucao BCB n. 402 of 22/7/2024, and IN BCB n. 513/2024 art. 17 II puts the Pix Automatico procedures in force on 2025-06-16, which is used here as the date the product's rules began to bind.", "source_edition": "Regulamento Pix annexed to Resolucao BCB n. 1/2020, consolidated text as served on 2026-09-22, Chapter V, Section II; Requisitos Minimos para a Experiencia do Usuario version 7.3 of December 2025; its cover announces version 7.4 in force from 2027-03-01", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms art 11-U caput inciso V alineas a to f: the parameters an authorisation must at least cover are the receiving user permitted to send instructions, the payer set maximum with its floor, the pre-approved credit line option, the term if any, the periodicity, and the planned first payment date" }, { "source": "pix:src.bcb-requisitos-minimos-experiencia-usuario-7-3", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms chapter 15 item 16 that before confirming, the app must show the receiver and debtor identification, the payment object and its contract or customer reference, a fixed amount where set, and, item 25, the retry policy with the interest and fine warning for late payment" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:mandate.pix-automatico-authorisation", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "pix:state.recurrence-expired", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.automatico-what-the-payer-may-edit-and-when-it-bites", "id": "rule.automatico-what-the-payer-may-edit-and-when-it-bites", "rail": "pix", "class": "Rule", "name": "Pix Automatico: what the payer may change on a live authorisation", "statement": "The payer may cancel an authorisation at any time and may change it on their own where changes are allowed. What the payer's app must let them change is three settings per authorisation: the maximum per payment (on variable authorisations only), whether a pre-approved credit line may be used, and whether they are notified when a payment is scheduled. A new maximum applies to payments not yet scheduled and not to those already scheduled; if it falls below a payment already scheduled, the bank may offer to cancel that payment. The recurrence terms themselves, such as period, first date, amount and business, are not among the settings the payer can edit, and on the business's side a request already delivered cannot be corrected: a business that got something wrong cancels the recurrence and creates a new one.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "art. 11-Q par. 1 inciso IV and par. 3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-requisitos-minimos-experiencia-usuario-7-3", "section": "chapter 15 items 25, 28, 29, 30 and 31", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "section": "Annex IV section 4.2.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-automatico", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Regulamento Pix art. 11-Q par. 1 inciso IV, the Requisitos Minimos 7.3 chapter 15 items 25 and 28 to 31, and the Manual de Padroes para Iniciacao do Pix 2.10.0 Annex IV section 4.2.1, all read 2026-09-22. That the payer cannot edit the recurrence terms is read from the closed list of editable settings in item 28 and is [Inference]; no text says so in terms. The rulebook names no pause or suspension of an authorisation; the only ways out are cancellation and expiry.", "confidence": "medium" }, "currency": { "effective_since": "2025-06-16", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. The Regulamento's Pix Automatico subsection was added by Resolucao BCB n. 402 of 22/7/2024, and IN BCB n. 513/2024 art. 17 II puts the Pix Automatico procedures in force on 2025-06-16, which is used here as the date the product's rules began to bind.", "source_edition": "Regulamento Pix annexed to Resolucao BCB n. 1/2020, consolidated text as served on 2026-09-22, Chapter V, Section II; Requisitos Minimos para a Experiencia do Usuario version 7.3 of December 2025; its cover announces version 7.4 in force from 2027-03-01; Manual de Padroes para Iniciacao do Pix version 2.10.0 of 2026-08-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-requisitos-minimos-experiencia-usuario-7-3", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms chapter 15 item 28 that the payer may edit the maximum amount on variable authorisations, credit line use and scheduling notifications, that a new maximum applies only to future scheduling and not to payments already scheduled, and item 30 that a lowered maximum below an already scheduled payment lets the bank offer to cancel it" }, { "source": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms art 11-Q par 1 IV that the payer may cancel or, where allowed, alter the authorisation unilaterally at any time" }, { "source": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms at Annex IV section 4.1.1 that the receiving user may alter only the fields the PATCH endpoint exposes, and that changing any other recurrence parameter means cancelling the recurrence and asking the payer to confirm a new one" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:mandate.pix-automatico-authorisation", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.automatico-who-may-offer-and-who-may-collect", "id": "rule.automatico-who-may-offer-and-who-may-collect", "rail": "pix", "class": "Rule", "name": "Pix Automatico: every account provider offers it to payers, and only established businesses may collect", "statement": "Every participant that holds transactional accounts must offer Pix Automatico to its paying customers, though one serving business customers may ask the BCB to be excused for those customers, and the pain.012 code AP15 marks a request refused on that ground. Offering it to businesses that want to collect is optional, and only a legal person may collect: its CNPJ must have been active for at least six months and it must show no sign of fraud under the bank's own criteria, which must use the DICT's security data where the bank has access to it. The bank must vet the business before it signs up and for as long as the contract runs, weighing at least its registration data, its size and activity, the fit between its business and what it collects for, the DICT data, and its history with the bank. The business talks to its bank through the API Pix or a standardised file, and a salary account cannot be the paying account (pain.012 SA01).", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "arts. 11-S caput and paragraphs 1 and 3, and 11-T caput and paragraphs 1, 2, 3 and 7", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "section": "art. 15-A", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "section": "PAIN012.xlsx domain table, RejectReason AP15 and SA01", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-automatico", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Regulamento Pix arts. 11-S and 11-T (par. 1 as worded by Resolucao BCB n. 482/2025 from 2025-06-16), IN BCB n. 513/2024 art. 15-A (added by IN BCB n. 634/2025), and the pain.012 domain table in spi.5.12.1.zip, all read 2026-09-22.", "confidence": "high" }, "currency": { "effective_since": "2025-06-16", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. The Regulamento's Pix Automatico subsection was added by Resolucao BCB n. 402 of 22/7/2024, and IN BCB n. 513/2024 art. 17 II puts the Pix Automatico procedures in force on 2025-06-16, which is used here as the date the product's rules began to bind.", "source_edition": "Regulamento Pix annexed to Resolucao BCB n. 1/2020, consolidated text as served on 2026-09-22, Chapter V, Section II; Instrucao Normativa BCB n. 513 de 30/8/2024, consolidated text version 5.0 as served on 2026-09-22, with the amendments by IN BCB n. 614/2025, n. 634/2025 and n. 743/2026 shown in place; SPI message definitions spi.5.12.1.zip (in production since 2026-06-28) and spi.5.13.1.zip (production from 2026-10-25), domain tables", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms art 11-S caput and pars 1 and 3 that every account provider must offer Pix Automatico to payers, with an opt out the BCB may grant for business customers, and art 11-T caput, pars 1, 2, 3 and 7 that offering collection is optional, restricted to a legal person whose CNPJ has been active six months with no sign of fraud under the participant's own criteria informed by DICT data where available, and that the bank must vet the business before and during the contract" }, { "source": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms art 15-A that the receiving bank must vet the business before signing it up and during the contract, weighing at least its CNPJ and partner registration data, its capital type, its economic activity fit, its headcount and revenue, DICT security data where available, and its relationship history" }, { "source": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms in the PAIN012.xlsx domain table that AP15 (NotOffered) is used when the payer's participant opted out of offering Pix Automatico to legal person clients, and SA01 (SalaryAccountNotAuthorized) bars a salary account from being the paying account" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:mandate.pix-automatico-authorisation", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.cobranca-a-charge-takes-one-payment-and-an-identifier-is-never-reused", "id": "rule.cobranca-a-charge-takes-one-payment-and-an-identifier-is-never-reused", "rail": "pix", "class": "Rule", "name": "Pix Cobranca: one payment per charge, and a transaction identifier used once", "statement": "A charge is active until paid or removed. When a Pix carrying its transaction identifier arrives it becomes concluded, which is final: it takes no further payment and can be neither changed nor removed. Concluded speaks of the charge, not of the debt behind it. While active, the business may change a charge, and a new read of the QR code shows the change, or remove it, and a payer who then reads it must be told it was deleted. A dynamic QR code may mark itself as single use in BR Code field 01. The transaction identifier of a charge must be unique for that receiver at that bank and is never reused, not even after the charge was removed; it is 26 to 35 letters and digits. So an attempt that did not complete may be retried on the same still active charge, while a new charge always needs a new identifier.", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "section": "sections 2.7.1.1 and 2.7.2, and Annex I sections 5.1, 5.3.1, 6.5.2 and 6.5.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-cobranca", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:rule.cobranca-a-static-code-leaves-reconciliation-to-the-receiver", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Manual de Padroes para Iniciacao do Pix 2.10.0 sections 2.7.1.1, 2.7.2, Annex I sections 5.1, 5.3.1, 6.5.2 and 6.5.3, read 2026-09-22. That an incomplete attempt may be retried on the same active charge is [Inference]: the charge stays active until a Pix with its identifier is received.", "confidence": "high" }, "currency": { "effective_since": "Unknown: the provisions predate version 2.10.0 and their dates were not traced", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. Pix Cobranca entered the Regulamento on 2020-11-03 (Resolucao BCB n. 30/2020); the manual details read are those of version 2.10.0.", "source_edition": "Manual de Padroes para Iniciacao do Pix version 2.10.0 of 2026-08-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms at Annex I sections 5.1 and 5.3.1 that a charge's status moves to CONCLUIDA, which is final, once a matching Pix arrives, that a transaction identifier must be unique for that receiver at that PSP and 26 to 35 characters long, and is never reused even after cancellation or removal, and at sections 6.5.2 and 6.5.3 that an active charge may still be changed or removed" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:state.charge-active", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "pix:state.charge-concluded", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "pix:state.charge-removed-by-the-psp", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "pix:state.charge-removed-by-the-receiver", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.cobranca-a-due-date-charge-rolls-to-the-payers-next-business-day", "id": "rule.cobranca-a-due-date-charge-rolls-to-the-payers-next-business-day", "rail": "pix", "class": "Rule", "name": "Pix Cobranca: due date, grace period and the payer's holidays", "statement": "A due date charge must carry its due date, payable at any hour of that day, and a number of calendar days after it during which it can still be paid late. If either date falls on a weekend or on a holiday where the payer is, it moves to the next business day, and every date built on it (the grace period, the discount dates, when interest and the fine start) moves with it. The holidays that count are the payer's state and municipal ones: when the payer's app fetches the charge it sends the payer's IBGE municipality code and the date the payer means to pay, and the payee's bank uses them to price the charge. If the municipality is not sent the payee's bank assumes no state or municipal holiday applies; if the intended date is not sent it assumes the due date, or the day of the query once the charge is overdue. The manual names no list of holidays to consult.", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "section": "section 2.7.1.2 with footnotes 41, 44 and 45, and Annex III section 3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-cobranca", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Manual de Padroes para Iniciacao do Pix 2.10.0 section 2.7.1.2 and Annex III section 3, read 2026-09-22. The table in 2.7.1.2 marks the grace period mandatory and Annex III marks it optional on creation; both are cited as found.", "confidence": "high" }, "currency": { "effective_since": "Unknown: the provisions predate version 2.10.0 and their dates were not traced", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. Pix Cobranca entered the Regulamento on 2020-11-03 (Resolucao BCB n. 30/2020); the manual details read are those of version 2.10.0.", "source_edition": "Manual de Padroes para Iniciacao do Pix version 2.10.0 of 2026-08-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms at section 2.7.1.2 the payer municipality and intended payment date fields and their defaults when omitted, at footnote 44 that a due date falling on a weekend or the payer's holiday rolls automatically to the next business day, at footnote 45 the same for the post due date grace period end, and at Annex III section 3 that dependent dates such as the discount deadline roll with it and that the due date itself is payable at any hour of the day" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.cobranca-a-static-code-leaves-reconciliation-to-the-receiver", "id": "rule.cobranca-a-static-code-leaves-reconciliation-to-the-receiver", "rail": "pix", "class": "Rule", "name": "Pix QR codes: a static code's identifier is the receiver's to keep consistent", "statement": "The payee's bank cannot stop a transaction identifier repeating on static QR codes, because they are made without the API Pix and it never sees them. Sometimes repeating it is the point, as with a fixed code at a counter with no amount; sometimes it must not repeat, as with a code printed for one sale. Keeping payments on static codes consistent is left entirely to the receiver, and the API Pix only returns the payments that arrived with a given identifier. The identifier reaches the payee's bank on the pacs.008.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "section": "Annex I section 5.3.2 and section 2.4.1 footnote 6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.receiving-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-cobranca", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Manual de Padroes para Iniciacao do Pix 2.10.0 Annex I section 5.3.2 and section 2.4.1, read 2026-09-22.", "confidence": "high" }, "currency": { "effective_since": "Unknown: the provision predates version 2.10.0 and its date was not traced", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. Pix Cobranca entered the Regulamento on 2020-11-03 (Resolucao BCB n. 30/2020); the manual details read are those of version 2.10.0.", "source_edition": "Manual de Padroes para Iniciacao do Pix version 2.10.0 of 2026-08-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms at Annex I section 5.3.2 that the receiving bank cannot guard against a repeated identifier on a static QR code because such codes are not generated through the API Pix, that repetition is sometimes wanted and sometimes not, that consistency is left entirely to the receiving user, and that the API Pix only returns the Pix payments that carried a given identifier" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:rule.cobranca-a-charge-takes-one-payment-and-an-identifier-is-never-reused", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.cobranca-an-immediate-charge-lives-24-hours-by-default", "id": "rule.cobranca-an-immediate-charge-lives-24-hours-by-default", "rail": "pix", "class": "Rule", "name": "Pix Cobranca: how long an immediate charge stays payable", "statement": "An immediate charge is payable for the number of seconds its creator sets in the expiry field, counted from when it was created, and for 24 hours (86400 seconds) if the creator sets nothing. The receiving end user sets it through its bank's API Pix when it creates the charge. After it expires, the payee's bank may answer a request for the charge with an HTTP status that says so, such as 410 or 404, and the paying bank's reader has nothing to pay.", "rests_on": "rule", "facet": "hours", "parameters": { "time_window": { "count": 24, "unit": "hour", "from": "processing_date", "actor": "pix:role.receiving-user", "text": "default life of an immediate charge, from its creation, when the creator sets no expiry" } }, "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "section": "sections 2.7.1.1 and 2.7.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-cobranca", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Manual de Padroes para Iniciacao do Pix 2.10.0 sections 2.7.1.1 (calendario.expiracao) and 2.7.3, read 2026-09-22. That the paying app then has nothing to pay is [Inference] from 2.7.3.", "confidence": "high" }, "currency": { "effective_since": "Unknown: the default predates version 2.10.0 and its date was not traced", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. Pix Cobranca entered the Regulamento on 2020-11-03 (Resolucao BCB n. 30/2020); the manual details read are those of version 2.10.0.", "source_edition": "Manual de Padroes para Iniciacao do Pix version 2.10.0 of 2026-08-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms at section 2.7.1.1 that calendario.expiracao is optional, counted in seconds from the charge creation timestamp, defaulting to 86400 seconds (24 hours) when not set, and at section 2.7.3 that the receiving bank may answer a concluded, expired or removed charge's payload request with an HTTP status such as 410 or 404" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.cobranca-immediate-and-due-date-charges", "id": "rule.cobranca-immediate-and-due-date-charges", "rail": "pix", "class": "Rule", "name": "Pix Cobranca: a charge for immediate payment or for payment by a due date", "statement": "Pix Cobranca lets a receiving end user prepare and collect charges through its bank. An immediate charge is for business where payment happens when the charge is issued, such as a till or an online checkout. A due date charge can be paid later and can carry interest, a fine, other additions, a discount and other rebates. Once the payer starts paying a charge it becomes an ordinary Pix. Offering Pix Cobranca to receivers is optional for a participant, apart from the duty to give natural person customers a static QR code, but every account provider must be able to read a Pix Cobranca QR code and start a payment from it, and must let a payer schedule a due date charge for a future date. A payment initiator may choose not to read them. Contactless initiation of a charge is optional and, where offered, follows the manual from 2025-12-01.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "arts. 11-A, 11-B, 11-C, 11-D, 11-DA and 11-E", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.pix-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-cobranca", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Regulamento Pix arts. 11-A to 11-E in the consolidated text, read 2026-09-22.", "confidence": "high" }, "currency": { "effective_since": "2020-11-03", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. Pix Cobranca entered the Regulamento on 2020-11-03 (Resolucao BCB n. 30/2020); the manual details read are those of version 2.10.0.", "source_edition": "Regulamento Pix annexed to Resolucao BCB n. 1/2020, consolidated text as served on 2026-09-22, Chapter V, Section II", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms art 11-A incisos I and II that Pix Cobranca covers immediate and due date charges, the latter with interest, fines, other additions, discounts and rebates, art 11-B that a started payment runs as an ordinary Pix, art 11-C that offering it is optional apart from the static QR code duty in art 6 par 1 II, art 11-D that account providers must read the QR code and start the payment and must let the payer schedule a due date charge, art 11-DA and 11-E that contactless initiation and QR code reading are optional for the initiating participant and that contactless follows the manual from 2025-12-01" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.cobranca-static-dynamic-and-composite-qr-codes", "id": "rule.cobranca-static-dynamic-and-composite-qr-codes", "rail": "pix", "class": "Rule", "name": "Pix QR codes: static, dynamic and composite", "statement": "A static QR code carries everything inside the image: a DICT key, which is compulsory, and optionally a transaction identifier, free text, an amount and a withdrawal facilitator. A dynamic QR code carries the key and a URL at the payee's bank; the charge itself, with amount, identifier and the rest, is fetched from that URL when the code is read, so it can change over time and must be validated and queried after reading. A composite QR code adds a second URL pointing at Pix Automatico recurrence terms, with or without a static or dynamic charge alongside it. All three follow the BR Code layout, and a payer's app that cannot fetch the recurrence part must fall back to paying the rest as it would a plain code.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "section": "sections 2.4, 2.6, 2.7, 2.7.2 and 2.8, and footnote 87", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-cobranca", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-automatico", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Manual de Padroes para Iniciacao do Pix 2.10.0 sections 2.4 to 2.8, read 2026-09-22.", "confidence": "high" }, "currency": { "effective_since": "Unknown: the three kinds predate version 2.10.0 and their dates were not traced", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. Pix Cobranca entered the Regulamento on 2020-11-03 (Resolucao BCB n. 30/2020); the manual details read are those of version 2.10.0.", "source_edition": "Manual de Padroes para Iniciacao do Pix version 2.10.0 of 2026-08-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms sections 2.4.1 and 2.4.2 that a static code holds a compulsory DICT key and four optional fields while a dynamic code holds the key and a fetch URL, section 2.8 that a composite code has three configurations mixing recurrence with nothing, a static charge or a dynamic charge, and footnote 87 that a payer app unable to fetch the recurrence data falls back to the plain static QR code payment journey" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.cobranca-the-payees-bank-computes-the-final-amount", "id": "rule.cobranca-the-payees-bank-computes-the-final-amount", "rail": "pix", "class": "Rule", "name": "Pix Cobranca: who computes interest, fines, discounts and rebates", "statement": "The payee's bank computes the amount due on a due date charge, from the terms the business set when it created the charge (how any rebate, discount, interest and fine is calculated) and the payer's municipality and intended payment date. The charge the payer's app fetches always carries the final amount, which is compulsory, beside optional figures for the original amount, rebate, discount, interest and fine; where all of those except the original are zero the app shows only the final amount. So there is no case in which the app has to fall back to the original amount: a charge without a final amount does not meet the standard. A charge may not be built so that its discount could exceed the original amount.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "section": "sections 2.7.1.2 and Annex III sections 1 and 3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-cobranca", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Manual de Padroes para Iniciacao do Pix 2.10.0 section 2.7.1.2 (the valor object and its cardinalities) and Annex III sections 1 and 3, read 2026-09-22. The sentence that no fallback case exists is [Inference] from valor.final being mandatory in both charge payloads.", "confidence": "high" }, "currency": { "effective_since": "Unknown: the provisions predate version 2.10.0 and their dates were not traced", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. Pix Cobranca entered the Regulamento on 2020-11-03 (Resolucao BCB n. 30/2020); the manual details read are those of version 2.10.0.", "source_edition": "Manual de Padroes para Iniciacao do Pix version 2.10.0 of 2026-08-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms at section 2.7.1.2 that the payer app sends the payer municipality and intended payment date so the receiving bank can calculate the amount due, at section 2.7.1.2 field 4.6 and its explanatory text that valor.final is mandatory and the app shows only it when the other adjustment fields are zero, and at Annex III section 3 that a charge may not be built with a discount that could exceed the original amount" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.consumer-law-a-complaint-can-start-a-recovery", "id": "rule.consumer-law-a-complaint-can-start-a-recovery", "rail": "pix", "class": "Rule", "name": "A complaint can start a recovery", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "art. 78-N (introduced by Resolucao BCB n. 493 de 28/8/2025)", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-manual-operacional-dict-8-5", "section": "section 10 footnote 7 for the four fraud grounds, section 10.1 SituationType values, section 20 opening paragraphs for the trigger", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.med", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Restated 2026-09-22 from Regulamento Pix art. 78-N and Manual Operacional do DICT 8.5 sections 10, 10.1 and 20, both opened and read in full for this record. The trigger is art. 78-N; the wider trigger and the SituationType values are the DICT manual's; the four fraud grounds are footnote 7 to section 10, regrouped here by whether the payer authorised the payment rather than kept in the manual's order. Unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2024-11-01", "effective_to": null, "effective_note": "Split out of pix:consumer-law by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's. Corrected 2026-09-22: the statement carried over from the fact followed Manual Operacional do DICT 8.5 section 10 footnote 7 in the manual's own clause order, which rule 3 forbids. It has been rewritten from a fresh reading of the manual and of Regulamento art. 78-N, grouping the fraud grounds by whether the payer authorised the payment, and the record awaits re-validation.", "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": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.consumer-law-a-fee-rule-and-a-disclosure-rule", "id": "rule.consumer-law-a-fee-rule-and-a-disclosure-rule", "rail": "pix", "class": "Rule", "name": "A fee rule and a disclosure rule", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "art. 87 caput and paragrafo unico", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-resolucao-19-2020-tarifas", "section": "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)", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.pix-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Restated 2026-09-22 from Regulamento Pix art. 87 and from Resolucao BCB n. 19/2020, which was opened and read in full for this record after two earlier passes cited it unread. Disclosure is art. 87 and its paragrafo unico; the charging rules are arts. 3 and 4 of the resolution and the disclosure of the amount charged is its art. 7, regrouped here by where the customer meets the figure rather than kept in the article's inciso order. Unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2024-11-01", "effective_to": null, "effective_note": "Split out of pix:consumer-law by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's. Corrected 2026-09-22: the second half of the statement rested on Resolucao BCB n. 19/2020, which nobody had opened and which sat as unverified text inside the Regulamento link's section. The resolution has now been read in full, it says what the record claimed, and it is cited through its own RuleSource, pix:src.bcb-resolucao-19-2020-tarifas. What it actually charges for and where the amount must be shown are stated for the first time. The record awaits re-validation.", "source_edition": "Regulamento Pix (Resolucao BCB n. 1/2020), consolidated version 41; Resolucao BCB n. 19/2020 consolidated text, VersaoNormativo 3, amendments listed through Resolucao BCB n. 136 de 2/9/2021; 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": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.consumer-law-a-freeze-the-customer-never-has-to-ask-for", "id": "rule.consumer-law-a-freeze-the-customer-never-has-to-ask-for", "rail": "pix", "class": "Rule", "name": "A freeze the customer never has to ask for", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "art. 39-B caput and paragraphs 2 to 6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.bloqueio-cautelar", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:consumer-law by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "medium" }, "currency": { "effective_since": "2024-11-01", "effective_to": null, "effective_note": "Split out of pix:consumer-law by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 39-B confirms the receiving participant must freeze suspected funds at the moment of credit, tell the customer immediately, hold for up to 72 hours, then either return the funds under the MED or lift the block, all without any action by the payer." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.consumer-law-the-general-customer-protection-resolution-has-a", "id": "rule.consumer-law-the-general-customer-protection-resolution-has-a", "rail": "pix", "class": "Rule", "name": "The general customer protection resolution has a hole in it", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "pix:src.cmn-resolucao-4949-2021", "section": "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", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.pix-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:consumer-law by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "medium" }, "currency": { "effective_since": "2024-11-01", "effective_to": null, "effective_note": "Split out of pix:consumer-law by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.cmn-resolucao-4949-2021", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 2 and art. 3 inciso II confirm fair and equitable treatment weighed against the customer's vulnerabilities; art. 4 incisos I, III, IV, V and VII confirm products matched to customer need, clear explanation of rights costs and risks, plain contract and statement wording, naming who was paid in statements, and no unreasonable barriers to service, closure or switching; art. 1 caput and par. 1, wording from 1/3/2024 by Resolucao CMN n. 5.117/2024, confirm the resolution does not apply to payment institutions, which follow whatever the BCB issues for them instead." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.consumer-law-the-limit-panel-must-be-where-the-customer-from-2026", "id": "rule.consumer-law-the-limit-panel-must-be-where-the-customer-from-2026", "rail": "pix", "class": "Rule", "name": "The limit panel must be where the customer already is, from 2026-10-01", "statement": "From 2026-10-01 a bank serving individuals still has to offer limit management inside the app its customers start a Pix from, but the panel no longer has to include a contactless limit. It must cover raising and lowering the general Pix limit, the Pix Automatico and Pix Agendado daily limits and the withdrawal and change limit, and registering chosen payees for a ceiling of their own; a customer may also ask for a general limit of zero. An account provider whose mobile app is supplied by another Pix participant does not have to offer the panel.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-in-746-2026-limites", "section": "art. 1 (new wording of IN 512 art. 10 par. 2 IV and V), art. 2 item I (revocation of art. 10 par. 2 VI) and art. 3 (in force 2026-10-01)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-in-512-2024-limites", "section": "art. 10 caput and paragraphs 1, 2 and 5, and art. 3 par. 14, as consolidated in VersaoNormativo 4", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "supersedes", "to": "pix:rule.consumer-law-the-limit-panel-must-be-where-the-customer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:rule.limits-the-user-can-drive-the-limit-in-both-directions-from-2026", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "IN BCB n. 746 de 16/6/2026, read in full 2026-09-24 from the BCB normativos data, applied to the consolidated IN BCB n. 512/2024 (VersaoNormativo 4) art. 10 and art. 3 par. 14, read the same day. The new wording of art. 10 par. 2 IV and V changes only the list punctuation so that V closes the list. The exemption is art. 10 par. 5, which IN 746 does not touch.", "confidence": "high" }, "currency": { "effective_since": "2026-10-01", "effective_to": null, "effective_note": "Drafted 2026-09-24 for change calendar decision 3 from the documents named in basis. Approved 2026-06-16 (IN BCB n. 746/2026, published 2026-06-17); in force 2026-10-01. Until then pix:rule.consumer-law-the-limit-panel-must-be-where-the-customer governs.", "source_edition": "IN BCB n. 746 de 16/6/2026, VersaoNormativo 1; IN BCB n. 512/2024, consolidated text, VersaoNormativo 4", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-in-746-2026-limites", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms IN BCB 746/2026 revokes IN BCB 512/2024 art. 10 paragraph 2 item VI, the contactless line in the limit panel, and reworks items IV and V only in punctuation, effective 2026-10-01, so the panel a bank must offer inside its own payment-initiating app keeps covering the general Pix limit, the Pix Automatico and Pix Agendado daily limits, the withdrawal and change limit, and payee registration, with a zero option under art. 3 paragraph 14. Confirms the exemption at art. 10 paragraph 5 for an account provider whose mobile app is supplied by another Pix participant, which IN BCB 746/2026 does not touch." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.consumer-law-the-limit-panel-must-be-where-the-customer", "id": "rule.consumer-law-the-limit-panel-must-be-where-the-customer", "rail": "pix", "class": "Rule", "name": "The limit panel must be where the customer already is", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-in-512-2024-limites", "section": "arts. 10 caput and paragraphs 1 and 2, and 3 par. 14", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:rule.limits-the-user-can-drive-the-limit-in-both-directions", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:consumer-law by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from and the see_also link to the Rule that states the same provision at another scope.", "confidence": "medium" }, "currency": { "effective_since": "2024-11-01", "effective_to": "2026-10-01", "effective_note": "Split out of pix:consumer-law by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's. Stops applying 2026-10-01, when IN BCB n. 746 de 16/6/2026 (arts. 1 to 3) takes the contactless item out of the limit panel (IN 512 art. 10 par. 2 VI revoked); the draft successor is pix:rule.consumer-law-the-limit-panel-must-be-where-the-customer-from-2026.", "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": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-in-512-2024-limites", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 10 caput and par. 1 confirm the limit management feature must sit inside the app the individual customer uses to pay, and par. 2 confirms it must cover the general and night limits, the withdrawal and change limit, the Pix Agendado limit, the Pix Automatico limit, named payee limits and the contactless limit; art. 3 par. 14 confirms a customer may set any of these to zero on request." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:rule.consumer-law-the-limit-panel-must-be-where-the-customer-from-2026", "type": "supersedes", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.consumer-law-the-night-ceiling-is-the-single-most-concrete", "id": "rule.consumer-law-the-night-ceiling-is-the-single-most-concrete", "rail": "pix", "class": "Rule", "name": "The night ceiling is the single most concrete protection", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-in-512-2024-limites", "section": "art. 3 par. 7 (wording by IN BCB n. 669 de 29/9/2025) with paragraphs 2 to 6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:rule.limits-the-night-limit-for-person-to-person", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:consumer-law by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from and the see_also link to the Rule that states the same provision at another scope.", "confidence": "medium" }, "currency": { "effective_since": "2024-11-01", "effective_to": null, "effective_note": "Split out of pix:consumer-law by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-in-512-2024-limites", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 3 par. 7, wording by Instrucao Normativa BCB n. 669 de 29/9/2025, confirms the R,000.00 default night ceiling between individuals unless the customer expressly asks for something else; paragraphs 2 to 6 confirm the night period runs 20:00 to 06:00 by default or 22:00 to 06:00 where the participant offers that choice and the customer takes it, and that the clock is the payer's registered home town or Brasilia time at the participant's choice." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.consumer-law-the-rulebook-obliges-a-good-experience-in-terms", "id": "rule.consumer-law-the-rulebook-obliges-a-good-experience-in-terms", "rail": "pix", "class": "Rule", "name": "The rulebook obliges a good experience, in terms", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "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)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.pix-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:consumer-law by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "medium" }, "currency": { "effective_since": "2024-11-01", "effective_to": null, "effective_note": "Split out of pix:consumer-law by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 86 caput incisos I to IX confirm the nine listed qualities including simplicity, ease of finding options, security, clear commands, agility, accuracy, transparency and convenience, and paragrafo unico incisos I to IX, the last added by Resolucao BCB n. 402 de 22/7/2024, confirm the duty reaches key management, authentication, sending, receiving and returning Pix, and since that amendment Pix Automatico and Pix Agendado." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.decision-points-is-the-suspicion-well-founded", "id": "rule.decision-points-is-the-suspicion-well-founded", "rail": "pix", "class": "Rule", "name": "Is the suspicion well founded", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "arts. 38 inciso II, 39 inciso I, 39-B caput and 41-B caput inciso I", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:decision-points by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-01", "effective_to": null, "effective_note": "Split out of pix:decision-points by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:decision-points, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.decision-points-what-to-do-at-the-end-of-72-hours", "id": "rule.decision-points-what-to-do-at-the-end-of-72-hours", "rail": "pix", "class": "Rule", "name": "What to do at the end of 72 hours", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "art. 39-B paragraphs 5 and 6 incisos I and II", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.bloqueio-cautelar", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:decision-points by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-01", "effective_to": null, "effective_note": "Split out of pix:decision-points by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:decision-points, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.decision-points-where-the-dict-decides-instead-of-a-person", "id": "rule.decision-points-where-the-dict-decides-instead-of-a-person", "rail": "pix", "class": "Rule", "name": "Where the DICT decides instead of a person", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-manual-operacional-dict-8-5", "section": "sections 20.1.2 and 20.1.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.bcb", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:decision-points by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-01", "effective_to": null, "effective_note": "Split out of pix:decision-points by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-manual-operacional-dict-8-5", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Section 20.1.2 confirms the tracking graph is built from the recovering participant's own TrackingGraphParameters against minimum criteria the central bank sets and communicates to participants; section 20.1.3 confirms the block path priority list is chosen by the DICT's own algorithm under four stated properties rather than by either bank." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.decision-points-whether-to-accept-an-infraction-notice-about", "id": "rule.decision-points-whether-to-accept-an-infraction-notice-about", "rail": "pix", "class": "Rule", "name": "Whether to accept an infraction notice about your own customer", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-manual-operacional-dict-8-5", "section": "section 20.1.5", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "arts. 78-G caput and 41-I caput inciso I", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.notificacao-de-infracao", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:decision-points by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-01", "effective_to": null, "effective_note": "Split out of pix:decision-points by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:decision-points, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.decision-points-whether-to-cancel-a-recovery-you-opened", "id": "rule.decision-points-whether-to-cancel-a-recovery-you-opened", "rail": "pix", "class": "Rule", "name": "Whether to cancel a recovery you opened", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-manual-operacional-dict-8-5", "section": "sections 20.1.5, 20.1.6 and 20.1.10", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.med", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:decision-points by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-01", "effective_to": null, "effective_note": "Split out of pix:decision-points by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-manual-operacional-dict-8-5", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Section 20.1.5 confirms the recovering participant must cancel where it concludes there is no fraud even after receiving participants have closed their analysis; section 20.1.6 confirms a 72 hour window after analysis to start the return during which it may keep analysing, with automatic completion if the window lapses; section 20.1.10 confirms cancelling obliges repayment of funds already collected, which lapsing does not." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.decision-points-whether-to-freeze-money-as-it-lands", "id": "rule.decision-points-whether-to-freeze-money-as-it-lands", "rail": "pix", "class": "Rule", "name": "Whether to freeze money as it lands", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "art. 39-B caput and paragraphs 1 and 4, with par. 7 revoked by Resolucao BCB n. 506 de 26/9/2025", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.bloqueio-cautelar", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:rule.liability-the-duty-to-freeze-on-arrival", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:decision-points by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from and the see_also link to the Rule that states the same provision at another scope.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-01", "effective_to": null, "effective_note": "Split out of pix:decision-points by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:decision-points, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.decision-points-whether-to-hold-a-payment-before-it-settles", "id": "rule.decision-points-whether-to-hold-a-payment-before-it-settles", "rail": "pix", "class": "Rule", "name": "Whether to hold a payment before it settles", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-manual-de-tempos-do-pix-7-0", "section": "section 2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:decision-points by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-01", "effective_to": null, "effective_note": "Split out of pix:decision-points by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-manual-de-tempos-do-pix-7-0", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Section 2 confirms the payer participant may extend authorization up to 30 minutes on business days 08:00 to 20:00 Brasilia time or 60 minutes otherwise, that withdrawal, change and Open Finance smart transfers are excluded, and that the payer must be offered a cancel option during the hold." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.decision-points-whether-to-honour-a-return-request-at-all", "id": "rule.decision-points-whether-to-honour-a-return-request-at-all", "rail": "pix", "class": "Rule", "name": "Whether to honour a return request at all", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-manual-operacional-dict-8-5", "section": "section 17, closing field table", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.med", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:rule.refund-grounds-a-receiving-bank-may-give-for-paying", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:decision-points by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from and the see_also link to the Rule that states the same provision at another scope.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-01", "effective_to": null, "effective_note": "Split out of pix:decision-points by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-manual-operacional-dict-8-5", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Section 17 closing field table confirms the receiving participant answers totally accepted, partially accepted or rejected, and that a rejected answer needs one of no_balance, account_closure or a generic other reason not covered by the first two." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.decision-points-whether-to-lift-a-block-on-a-flagged-account", "id": "rule.decision-points-whether-to-lift-a-block-on-a-flagged-account", "rail": "pix", "class": "Rule", "name": "Whether to lift a block on a flagged account", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "art. 89 par. 10 (introduced by Resolucao BCB n. 425 de 16/10/2024, in effect from 2024-11-01)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.notificacao-de-infracao", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:decision-points by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "medium" }, "currency": { "effective_since": "2024-11-01", "effective_to": null, "effective_note": "Split out of pix:decision-points by the 2026-09 Orca Core migration; no rule change identified. The line itself dates this from 2024-11-01.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:decision-points, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.decision-points-whether-to-open-a-recovery-on-the-customers-word", "id": "rule.decision-points-whether-to-open-a-recovery-on-the-customers-word", "rail": "pix", "class": "Rule", "name": "Whether to open a recovery on the customer's word", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "art. 78-N (introduced by Resolucao BCB n. 493 de 28/8/2025)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-manual-operacional-dict-8-5", "section": "sections 20.1.1 and 20.1.10", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.med", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:decision-points by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-01", "effective_to": null, "effective_note": "Split out of pix:decision-points by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:decision-points, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.decision-points-whether-to-raise-a-customers-limit", "id": "rule.decision-points-whether-to-raise-a-customers-limit", "rail": "pix", "class": "Rule", "name": "Whether to raise a customer's limit", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-in-512-2024-limites", "section": "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)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:decision-points by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-01", "effective_to": null, "effective_note": "Split out of pix:decision-points by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-in-512-2024-limites", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 11 confirms a reduction request must be honoured immediately, and art. 12 caput with paragraphs 1 and 2 confirm an increase is accepted at the participant's discretion, answered in 24 to 48 hours generally or at most 8 hours for Pix Automatico." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.finality-fourth-layer-finality-does-not-settle-who-bears", "id": "rule.finality-fourth-layer-finality-does-not-settle-who-bears", "rail": "pix", "class": "Rule", "name": "Fourth layer: finality does not settle who bears the loss", "statement": "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.", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "arts. 41-B caput incisos I to III and 41-B par. 1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.med", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:finality by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2022-04-01", "effective_to": null, "effective_note": "Split out of pix:finality by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 41-B caput incisos I to III confirm the three MED grounds, fraud, IT failure and a faulty Pix Automatico payment, and par. 1 confirms it never covers a dispute about the underlying deal or funds that reached a good faith third party." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.finality-how-fast-that-has-to-happen", "id": "rule.finality-how-fast-that-has-to-happen", "rail": "pix", "class": "Rule", "name": "How fast that has to happen", "statement": "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.", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-manual-de-tempos-do-pix-7-0", "section": "sections 1.1 and 1.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.bcb", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-agendado", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:finality by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2022-04-01", "effective_to": null, "effective_note": "Split out of pix:finality by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-manual-de-tempos-do-pix-7-0", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Sections 1.1 and 1.2 confirm the time count starts when the paying participant receives the order from the payer and that a payment not settled within the limit is always rejected by the SPI once the order is inside it." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:rule.hours-payment-clocks-40-seconds-or-45-minutes", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.settlement-two-message-channels-two-clocks", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.finality-one-cancellation-window-does-exist-before", "id": "rule.finality-one-cancellation-window-does-exist-before", "rail": "pix", "class": "Rule", "name": "One cancellation window does exist, before settlement", "statement": "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.", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-manual-de-tempos-do-pix-7-0", "section": "section 2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:finality by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2022-04-01", "effective_to": null, "effective_note": "Split out of pix:finality by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-manual-de-tempos-do-pix-7-0", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Section 2 confirms the payer must be notified and offered a cancel option while the payer PSP holds a suspect payment during the 30 or 60 minute extended authorization window, which ends once the payment settles." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.finality-second-layer-a-return-is-a-new-payment-not-a", "id": "rule.finality-second-layer-a-return-is-a-new-payment-not-a", "rail": "pix", "class": "Rule", "name": "Second layer: a return is a new payment, not a reversal", "statement": "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.", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "arts. 40 par. 2 and 41-A caput inciso I", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.devolucao", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:finality by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2022-04-01", "effective_to": null, "effective_note": "Split out of pix:finality by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 40 confirms a devolucao moves funds already available in the receiving account, art. 40 par. 2 confirms multiple partial returns up to the total original value, and art. 41-A caput inciso I confirms every return presupposes sufficient funds in that account." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.finality-the-moment-of-finality", "id": "rule.finality-the-moment-of-finality", "rail": "pix", "class": "Rule", "name": "The moment of finality", "statement": "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.", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "section": "art. 40 caput and art. 40 par. 1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.bcb", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:finality by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2022-04-01", "effective_to": null, "effective_note": "Split out of pix:finality by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:finality, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.finality-the-system-presumes-the-order-is-good", "id": "rule.finality-the-system-presumes-the-order-is-good", "rail": "pix", "class": "Rule", "name": "The system presumes the order is good", "statement": "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.", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "section": "art. 41, with arts. 34, 36 and 37", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.bcb", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:finality by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2022-04-01", "effective_to": null, "effective_note": "Split out of pix:finality by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:finality, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.finality-there-is-no-sender-cancellation-and-no", "id": "rule.finality-there-is-no-sender-cancellation-and-no", "rail": "pix", "class": "Rule", "name": "There is no sender cancellation and no cancellation message", "statement": "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.", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-catalogo-servicos-sfn-vol-vi-5-12", "section": "message chapter, pp. 17 to 21 (absence of a cancellation message for a settled payment)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-manual-de-tempos-do-pix-7-0", "section": "sections 3.3 and 3.4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:finality by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "high" }, "currency": { "effective_since": "2022-04-01", "effective_to": null, "effective_note": "Split out of pix:finality by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-catalogo-servicos-sfn-vol-vi-5-12", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "The message chapter lists every message the catalog defines and names no camt.056 and no message that recalls a settled payment." }, { "source": "pix:src.bcb-manual-de-tempos-do-pix-7-0", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Sections 3.3 and 3.4 confirm pain.011 cancels a Pix Automatico authorization or recurrence and camt.055 cancels a scheduled debit or a charge, in both cases before the payment they relate to has settled." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:rule.recall-no-cancellation-no-recall-message", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.finality-third-layer-the-money-can-be-frozen-the-instant", "id": "rule.finality-third-layer-the-money-can-be-frozen-the-instant", "rail": "pix", "class": "Rule", "name": "Third layer: the money can be frozen the instant it lands", "statement": "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.", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "art. 39-B caput and paragraphs 2, 4 and 5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.bloqueio-cautelar", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:finality by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2022-04-01", "effective_to": null, "effective_note": "Split out of pix:finality by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 39-B caput and paragraphs 2, 4 and 5 confirm the freeze is simultaneous with the credit, capped at 72 hours, and used by the receiving participant to evaluate whether indicia support the suspicion of fraud." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:rule.liability-the-duty-to-freeze-on-arrival", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.hours-an-instant-payment-is-defined-as-always", "id": "rule.hours-an-instant-payment-is-defined-as-always", "rail": "pix", "class": "Rule", "name": "An instant payment is defined as always available", "statement": "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.", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "section": "art. 2 inciso II", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:hours by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "high" }, "currency": { "effective_since": "2022-04-01", "effective_to": null, "effective_note": "Split out of pix:hours by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:hours, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.hours-availability-is-measured-and-has-a-floor", "id": "rule.hours-availability-is-measured-and-has-a-floor", "rail": "pix", "class": "Rule", "name": "Availability is measured and has a floor", "statement": "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.", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "section": "arts. 2 inciso XVI and 5 inciso III", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-manual-de-tempos-do-pix-7-0", "section": "sections 6.1.2 and 6.2.3", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.direct-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Restated 2026-09-22 from the Regulamento do SPI consolidated text (VersaoNormativo 6) and Manual de Tempos do Pix 7.0, both opened and read for this record. The index formula and its three month window are art. 2 inciso XVI; the 99.90 percent floor and the duty it falls on are art. 5 inciso III, which is the provision the record previously mis-cited as art. 13 inciso III. The DICT targets and the outage threshold are Manual de Tempos sections 6.1.2 and 6.2.3. Unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2022-04-01", "effective_to": null, "effective_note": "Split out of pix:hours by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's. Corrected 2026-09-22: the citation named Regulamento do SPI art. 13 inciso III, which does not exist; art. 13 has only incisos I and II and is about who must join the SPI. The 99.90 percent floor is art. 5 inciso III, and the citation now says so. The claim itself was sound and has been restated from a fresh reading, adding the three month measurement window, the DICT targets and the outage threshold. The record awaits re-validation.", "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": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.hours-banks-must-be-open-too", "id": "rule.hours-banks-must-be-open-too", "rail": "pix", "class": "Rule", "name": "Banks must be open too", "statement": "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.", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "section": "arts. 18 incisos II and III, 15 par. 4, and 11 par. unico", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.direct-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:hours by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2022-04-01", "effective_to": null, "effective_note": "Split out of pix:hours by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:hours, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.hours-messages-are-in-utc-rules-speak-brasilia", "id": "rule.hours-messages-are-in-utc-rules-speak-brasilia", "rail": "pix", "class": "Rule", "name": "Messages are in UTC, rules speak Brasilia", "statement": "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.", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-catalogo-servicos-sfn-vol-vi-5-12", "section": "date and time section, p. 12", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "art. 82 caput and par. unico", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "section": "art. 10", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:hours by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "high" }, "currency": { "effective_since": "2022-04-01", "effective_to": null, "effective_note": "Split out of pix:hours by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-catalogo-servicos-sfn-vol-vi-5-12", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "The date and time section confirms every SPI message carries a UTC timestamp marked with the Z indicator and confirms Brasilia standard time is UTC minus three hours." }, { "source": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 82 caput confirms DICT hours obey UTC unless stated otherwise, and par. unico confirms the time on the Banco Central do Brasil's own equipment prevails over any other for all purposes." }, { "source": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 10 confirms the time on the Banco Central do Brasil's own equipment prevails over any other for all SPI purposes, and its par. unico confirms hours reported by the SPI and its participants obey the UTC format unless the BCB states otherwise." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.hours-payment-clocks-40-seconds-or-45-minutes", "id": "rule.hours-payment-clocks-40-seconds-or-45-minutes", "rail": "pix", "class": "Rule", "name": "Payment clocks: 40 seconds or 45 minutes", "statement": "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.", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-manual-de-tempos-do-pix-7-0", "section": "sections 1.1, 1.2 and 1.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "pix:rule.finality-how-fast-that-has-to-happen", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:hours by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the see_also link to the Rule that states the same provision at another scope.", "confidence": "high" }, "currency": { "effective_since": "2022-04-01", "effective_to": null, "effective_note": "Split out of pix:hours by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-manual-de-tempos-do-pix-7-0", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Sections 1.1, 1.2 and 1.3 confirm the 40 second and 45 minute limits by channel and confirm that for a payment settled outside the SPI, the participant responsible for settlement must itself effect the rejection rather than the SPI." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.hours-the-dict-never-closes-either", "id": "rule.hours-the-dict-never-closes-either", "rail": "pix", "class": "Rule", "name": "The DICT never closes either", "statement": "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.", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "art. 79 (wording from 2023-01-01, Resolucao BCB n. 269/2022)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.bcb", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:hours by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2023-01-01", "effective_to": null, "effective_note": "Split out of pix:hours by the 2026-09 Orca Core migration; no rule change identified. The line itself dates this from 2023-01-01.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 79, wording from 2023-01-01 by Resolucao BCB n. 269/2022, confirms every DICT functionality in Chapter XIII Section III runs 24 hours a day every day of the year, which covers registration, deletion, alteration, portability, ownership claim, query, infraction notice, key verification and return request as the same provision listed them in its 2021 wording." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.hours-the-fraud-hold-runs-on-business-hours", "id": "rule.hours-the-fraud-hold-runs-on-business-hours", "rail": "pix", "class": "Rule", "name": "The fraud hold runs on business hours", "statement": "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.", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-manual-de-tempos-do-pix-7-0", "section": "section 2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:hours by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2022-04-01", "effective_to": null, "effective_note": "Split out of pix:hours by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-manual-de-tempos-do-pix-7-0", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Section 2 confirms the 30 minute window on business days 08:00 to 20:00 Brasilia time and 60 minutes otherwise, excludes withdrawal, change and Open Finance smart transfers, and confirms the payer must be told the payment is under analysis and offered the option to cancel." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.hours-the-night-period-is-a-value-rule-not-a-closing", "id": "rule.hours-the-night-period-is-a-value-rule-not-a-closing", "rail": "pix", "class": "Rule", "name": "The night period is a value rule, not a closing", "statement": "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.", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-in-512-2024-limites", "section": "art. 3 paragraphs 2, 3, 4, 5 and 6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:hours by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2022-04-01", "effective_to": null, "effective_note": "Split out of pix:hours by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-in-512-2024-limites", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 3 paragraphs 2 to 6 confirm the day period is generally 06:00 to 20:00 and the night period 20:00 to 06:00, measured at the payer's registered domicile or Brasilia time at the participant's choice, and confirm a participant may let the customer move the night start to 22:00, in which case the day period runs to 22:00." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.hours-the-spi-never-closes", "id": "rule.hours-the-spi-never-closes", "rail": "pix", "class": "Rule", "name": "The SPI never closes", "statement": "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.", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "section": "art. 8 caput and par. unico", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.bcb", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:hours by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2022-04-01", "effective_to": null, "effective_note": "Split out of pix:hours by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:hours, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.hours-what-a-bank-must-offer-its-own-customers-is", "id": "rule.hours-what-a-bank-must-offer-its-own-customers-is", "rail": "pix", "class": "Rule", "name": "What a bank must offer its own customers is narrower", "statement": "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.", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "art. 80 caput (wording from 2021-11-01, Resolucao BCB n. 103/2021) and art. 80 par. unico", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.pix-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:hours by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2021-11-01", "effective_to": null, "effective_note": "Split out of pix:hours by the 2026-09 Orca Core migration; no rule change identified. The line itself dates this from 2021-11-01.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 80 caput, wording from 2021-11-01 by Resolucao BCB n. 103/2021, confirms registration, deletion, portability and ownership claim need only be offered to end users 08:00 to 20:00 Brasilia time every day of the year, and par. unico confirms a participant may offer them at other hours the DICT is up at its own discretion." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.liability-a-bad-rejection-makes-the-receiving-bank", "id": "rule.liability-a-bad-rejection-makes-the-receiving-bank", "rail": "pix", "class": "Rule", "name": "A bad rejection makes the receiving bank answerable", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "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)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.notificacao-de-infracao", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:liability by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2024-11-01", "effective_to": null, "effective_note": "Split out of pix:liability by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:liability, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.liability-access-devices-must-be-registered", "id": "rule.liability-access-devices-must-be-registered", "rail": "pix", "class": "Rule", "name": "Access devices must be registered", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "art. 89 paragraphs 6, 7, 8 and 9 (wordings by Resolucao BCB n. 457 de 6/3/2025)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.pix-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:liability by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2024-11-01", "effective_to": null, "effective_note": "Split out of pix:liability by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:liability, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.liability-an-accepted-notice-shuts-the-account-out-of-pix", "id": "rule.liability-an-accepted-notice-shuts-the-account-out-of-pix", "rail": "pix", "class": "Rule", "name": "An accepted notice shuts the account out of Pix", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "art. 89 paragraphs 2 (wording by Resolucao BCB n. 506/2025) and 10 (by Resolucao BCB n. 425/2024)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.notificacao-de-infracao", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.pix-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:liability by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2024-11-01", "effective_to": null, "effective_note": "Split out of pix:liability by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:liability, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.liability-fraud-risk-management-is-a-stated-obligation", "id": "rule.liability-fraud-risk-management-is-a-stated-obligation", "rail": "pix", "class": "Rule", "name": "Fraud risk management is a stated obligation with contents", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "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)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.pix-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:liability by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2024-11-01", "effective_to": null, "effective_note": "Split out of pix:liability by the 2026-09 Orca Core migration; no rule change identified. The line itself dates this from 2024-11-01.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:liability, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.liability-non-compliance-is-a-supervision-matter", "id": "rule.liability-non-compliance-is-a-supervision-matter", "rail": "pix", "class": "Rule", "name": "Non compliance is a supervision matter", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "Chapter XIX (title as amended by Resolucao BCB n. 161 de 10/11/2021) and art. 30 par. 2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.bcb", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:liability by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2024-11-01", "effective_to": null, "effective_note": "Split out of pix:liability by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:liability, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.liability-pix-automatico-the-payers-bank-pays-first", "id": "rule.liability-pix-automatico-the-payers-bank-pays-first", "rail": "pix", "class": "Rule", "name": "Pix Automatico: the payer's bank pays first", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "arts. 41-A par. 2 incisos I and II and 11-V", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.med", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-automatico", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:liability by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from. The detail line of pix:refund that restated it was merged into it by the 2026-09 Orca Core migration under section 19 of docs/orca-core-v0-proposal.md. That line cited the same documents, at: Regulamento Pix, annex to Resolucao BCB n. 1/2020, consolidated version 41, arts. 41-A par. 2 incisos I and II (by Resolucao BCB n. 402 de 22/7/2024) and 11-V.", "confidence": "high" }, "currency": { "effective_since": "2024-11-01", "effective_to": null, "effective_note": "Split out of pix:liability by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:liability, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:rule.automatico-a-faulty-payment-is-refunded-within-24-hours", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.liability-the-duty-to-freeze-on-arrival", "id": "rule.liability-the-duty-to-freeze-on-arrival", "rail": "pix", "class": "Rule", "name": "The duty to freeze on arrival", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "art. 39-B caput and paragraphs 1 to 6 and 8 (introduced by Resolucao BCB n. 147/2021, in force from 2021-11-16)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.bloqueio-cautelar", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:rule.finality-third-layer-the-money-can-be-frozen-the-instant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:liability by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from and the see_also link to the Rule that states the same provision at another scope.", "confidence": "high" }, "currency": { "effective_since": "2021-11-16", "effective_to": null, "effective_note": "Split out of pix:liability by the 2026-09 Orca Core migration; no rule change identified. The line itself dates this from 2021-11-16.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:liability, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:rule.decision-points-whether-to-freeze-money-as-it-lands", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.liability-the-duty-to-reject-on-both-sides", "id": "rule.liability-the-duty-to-reject-on-both-sides", "rail": "pix", "class": "Rule", "name": "The duty to reject, on both sides", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "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)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:liability by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2024-11-01", "effective_to": null, "effective_note": "Split out of pix:liability by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:liability, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:rule.automatico-the-payers-bank-schedules-within-2-hours-or-refuses", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.liability-the-hold-is-no-longer-limited-to-individuals", "id": "rule.liability-the-hold-is-no-longer-limited-to-individuals", "rail": "pix", "class": "Rule", "name": "The hold is no longer limited to individuals", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "art. 39-B par. 7 (revoked by Resolucao BCB n. 506/2025)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.bloqueio-cautelar", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:liability by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2024-11-01", "effective_to": null, "effective_note": "Split out of pix:liability by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:liability, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.liability-the-requesting-participant-owns-the-med-return", "id": "rule.liability-the-requesting-participant-owns-the-med-return", "rail": "pix", "class": "Rule", "name": "The requesting participant owns the MED return", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "art. 41-H", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.med", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:liability by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2024-11-01", "effective_to": null, "effective_note": "Split out of pix:liability by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:liability, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.liability-what-the-bcb-says-the-rulebook-is", "id": "rule.liability-what-the-bcb-says-the-rulebook-is", "rail": "pix", "class": "Rule", "name": "What the BCB says the rulebook is", "statement": "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.", "rests_on": "guidance", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-in-512-2024-limites", "section": "NOTA appended to the published text, citing Voto 280/2021-BCB paragraph 8", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:liability by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. The detail line of pix:consumer-law that restated it was merged into it by the 2026-09 Orca Core migration under section 19 of docs/orca-core-v0-proposal.md. That line cited the same documents, at: IN BCB n. 512 de 30/8/2024, NOTA appended to the published text, citing Voto 280/2021-BCB paragraph 8.", "confidence": "high" }, "currency": { "effective_since": "2024-11-01", "effective_to": null, "effective_note": "Split out of pix:liability by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-in-512-2024-limites", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "The NOTA appended to the published text cites paragraph 8 of Voto 280/2021-BCB to say the Regulamento Pix and the documents that detail or complement it are not a binding regulatory act but are contractual in nature, and gives that as the reason changes to them are not subject to prior regulatory impact analysis." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.liability-where-disagreements-go", "id": "rule.liability-where-disagreements-go", "rail": "pix", "class": "Rule", "name": "Where disagreements go", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "art. 91 caput (wording from 2023-01-01, Resolucao BCB n. 269/2022) and art. 91 par. unico incisos I and II", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.pix-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:liability by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from. The detail line of pix:consumer-law that restated it was merged into it by the 2026-09 Orca Core migration under section 19 of docs/orca-core-v0-proposal.md. That line cited the same documents, at: Regulamento Pix, art. 91 caput (wording from 2023-01-01) and par. unico incisos I and II.", "confidence": "high" }, "currency": { "effective_since": "2023-01-01", "effective_to": null, "effective_note": "Split out of pix:liability by the 2026-09 Orca Core migration; no rule change identified. The line itself dates this from 2023-01-01.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:liability, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.limits-a-ceiling-aimed-at-the-weakest-technical-link", "id": "rule.limits-a-ceiling-aimed-at-the-weakest-technical-link", "rail": "pix", "class": "Rule", "name": "A ceiling aimed at the weakest technical link", "statement": "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.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "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)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.pix-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:limits by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2025-09-29", "effective_to": null, "effective_note": "Split out of pix:limits by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-in-512-2024-limites", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "This URL was corroborated in error against the wrong record; superseded by a correction against the Regulamento Pix source in the same session." }, { "source": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 37 par. 3 confirms the R150000,00 per payment cap on payment institutions under art. 3 par. 9 and on any participant reaching the network through a PSTI; paragraphs 4 to 6, current wording by Resolucao BCB n. 503/2025, confirm escaping it needs an accredited PSTI plus an independent auditor report on key custody and the other controls, or that the payment goes to the National Treasury or an FGTS charge." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.limits-contactless-and-initiation-without-redirection-from-2026", "id": "rule.limits-contactless-and-initiation-without-redirection-from-2026", "rail": "pix", "class": "Rule", "name": "Contactless and initiation without redirection, from 2026-10-01", "statement": "From 2026-10-01 the BCB sets no ceiling of its own for a Pix started by approximation or through a shared payment initiation service without redirection. The R$500.00 per payment cap goes, and so does the separate daily contactless limit the payer could choose inside it. The amending instruction names no replacement figure. What is left for these payments is the general limit regime of IN BCB n. 512/2024, which does not depend on how a Pix is started, and the unchanged art. 16-B, under which a participant may not give payments started through an initiation service limits different from other Pix.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-in-746-2026-limites", "section": "art. 2, items II and III (revocation of IN 512 arts. 16-A and 16-C), and art. 3 (in force 2026-10-01)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-in-512-2024-limites", "section": "arts. 3, 16-A, 16-B and 16-C as consolidated in VersaoNormativo 4", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "supersedes", "to": "pix:rule.limits-contactless-and-initiation-without-redirection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "IN BCB n. 746 de 16/6/2026, read in full 2026-09-24 from the BCB normativos data, and the consolidated IN BCB n. 512/2024 (VersaoNormativo 4) read the same day for the articles it revokes and the art. 16-B it leaves in place. That no replacement ceiling exists is read from the amending text, which revokes and sets nothing in their place. Not checked: whether any other BCB instrument, such as Resolucao BCB n. 406/2024 on shared initiation or the Requisitos Minimos para a Experiencia do Usuario, sets a contactless or no-redirection ceiling of its own; that is why confidence is medium.", "confidence": "medium" }, "currency": { "effective_since": "2026-10-01", "effective_to": null, "effective_note": "Drafted 2026-09-24 for change calendar decision 3 from the documents named in basis. Approved 2026-06-16 (IN BCB n. 746/2026, published 2026-06-17); in force 2026-10-01. Until then pix:rule.limits-contactless-and-initiation-without-redirection governs.", "source_edition": "IN BCB n. 746 de 16/6/2026, VersaoNormativo 1; IN BCB n. 512/2024, consolidated text, VersaoNormativo 4", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-in-746-2026-limites", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms IN BCB 746/2026 art. 2 revokes IN BCB 512/2024 arts. 16-A and 16-C, removing the R$500.00 per payment ceiling for contactless initiation and for shared initiation without redirection, plus the daily contactless limit inside it, effective 2026-10-01, with no replacement figure set. Confirms art. 16-B stays in force, so a participant still may not give payments started through an initiation service limits different from other Pix. Also checked Resolucao BCB 406/2024, which leaves value limits for shared initiation to be set by separate Banco Central instruments rather than setting one itself, the Manual de Padroes para Iniciacao do Pix, whose contactless section is purely technical and names no value limit, and the Requisitos Minimos para a Experiencia do Usuario, which does not mention contactless initiation at all; none of the three sets a replacement ceiling." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.limits-contactless-and-initiation-without-redirection", "id": "rule.limits-contactless-and-initiation-without-redirection", "rail": "pix", "class": "Rule", "name": "Contactless and initiation without redirection", "statement": "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.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-in-512-2024-limites", "section": "arts. 16-A and 16-C (introduced by IN BCB n. 629/2025, in force from 2025-12-01)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:limits by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2025-12-01", "effective_to": "2026-10-01", "effective_note": "Split out of pix:limits by the 2026-09 Orca Core migration; no rule change identified. The line itself dates this from 2025-12-01. Stops applying 2026-10-01, when IN BCB n. 746 de 16/6/2026 (arts. 2 and 3) revokes arts. 16-A and 16-C; the draft successor is pix:rule.limits-contactless-and-initiation-without-redirection-from-2026.", "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": "pix:src.bcb-in-512-2024-limites", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:limits, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:rule.limits-contactless-and-initiation-without-redirection-from-2026", "type": "supersedes", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.limits-cuts-are-immediate-increases-are-slow-on-purpose", "id": "rule.limits-cuts-are-immediate-increases-are-slow-on-purpose", "rail": "pix", "class": "Rule", "name": "Cuts are immediate, increases are slow on purpose", "statement": "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.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-in-512-2024-limites", "section": "arts. 11, 12 caput and paragraphs 1 and 2, 13 and 14", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:limits by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from. The detail line of pix:consumer-law that restated it was merged into it by the 2026-09 Orca Core migration under section 19 of docs/orca-core-v0-proposal.md. That line cited the same documents, at: IN BCB n. 512/2024, arts. 11, 12 caput and paragraphs 1 and 2, 13 and 14.", "confidence": "high" }, "currency": { "effective_since": "2025-09-29", "effective_to": null, "effective_note": "Split out of pix:limits by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-in-512-2024-limites", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:limits, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.limits-limits-an-operator-will-not-see-in-a-return", "id": "rule.limits-limits-an-operator-will-not-see-in-a-return", "rail": "pix", "class": "Rule", "name": "Limits an operator will not see in a return", "statement": "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.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-in-512-2024-limites", "section": "arts. 3 paragraphs 11 and 12, 6 par. 2, 7 par. 6 and 9 par. 5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.devolucao", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:limits by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2025-09-29", "effective_to": null, "effective_note": "Split out of pix:limits by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-in-512-2024-limites", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:limits, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.limits-no-limit-on-how-many", "id": "rule.limits-no-limit-on-how-many", "rail": "pix", "class": "Rule", "name": "No limit on how many", "statement": "Value is the only thing a Pix limit may measure. A participant cannot cap how many payments an end user sends or receives.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "art. 37-A (introduced by Resolucao BCB n. 79/2021, in force from 2021-04-01)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:limits by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "high" }, "currency": { "effective_since": "2021-04-01", "effective_to": null, "effective_note": "Split out of pix:limits by the 2026-09 Orca Core migration; no rule change identified. The line itself dates this from 2021-04-01.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 37-A, introduced by Resolucao BCB n. 79/2021 in force from 2021-04-01, confirms participants will not set a limit on how many payments an end user sends or receives." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.limits-the-day-limit-is-no-longer-pegged-to-ted", "id": "rule.limits-the-day-limit-is-no-longer-pegged-to-ted", "rail": "pix", "class": "Rule", "name": "The day limit is no longer pegged to TED", "statement": "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.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-in-512-2024-limites", "section": "art. 3 paragraphs 7 and 8 as revoked and replaced, with art. 3 par. 13 (introduced by IN BCB n. 669/2025)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:limits by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2025-09-29", "effective_to": null, "effective_note": "Split out of pix:limits by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-in-512-2024-limites", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:limits, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.limits-the-network-sets-no-ceiling", "id": "rule.limits-the-network-sets-no-ceiling", "rail": "pix", "class": "Rule", "name": "The network sets no ceiling", "statement": "The SPI accepts a credit order whatever its size. There is no network transaction limit to quote, and no minimum either.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "section": "art. 32", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.bcb", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:limits by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2025-09-29", "effective_to": null, "effective_note": "Split out of pix:limits by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 32 confirms credit orders of any value may be processed in the SPI, with no ceiling and no floor stated." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.limits-the-night-limit-for-person-to-person", "id": "rule.limits-the-night-limit-for-person-to-person", "rail": "pix", "class": "Rule", "name": "The night limit for person to person", "statement": "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.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-in-512-2024-limites", "section": "art. 3 par. 7 (wording by IN BCB n. 669 de 29/9/2025) with art. 3 paragraphs 1 to 6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:limits by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2025-09-29", "effective_to": null, "effective_note": "Split out of pix:limits by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-in-512-2024-limites", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:limits, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:rule.consumer-law-the-night-ceiling-is-the-single-most-concrete", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.limits-the-user-can-drive-the-limit-in-both-directions-from-2026", "id": "rule.limits-the-user-can-drive-the-limit-in-both-directions-from-2026", "rail": "pix", "class": "Rule", "name": "The user can drive the limit in both directions, from 2026-10-01", "statement": "From 2026-10-01 the limit controls a bank must give an individual customer, inside the app the customer pays from, no longer include a contactless limit. What remains is the ability to ask for a higher or a lower figure on the general Pix limit, on the Pix Automatico and Pix Agendado daily limits and on the withdrawal and change limit, and to register chosen accounts or payees so each can carry a daily ceiling of its own. On request, the general limit may be set at zero.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-in-746-2026-limites", "section": "art. 1 (new wording of IN 512 art. 10 par. 2 IV and V), art. 2 item I (revocation of art. 10 par. 2 VI) and art. 3 (in force 2026-10-01)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-in-512-2024-limites", "section": "art. 10 caput and paragraphs 1 and 2, and art. 3 par. 14, as consolidated in VersaoNormativo 4", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "supersedes", "to": "pix:rule.limits-the-user-can-drive-the-limit-in-both-directions", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "IN BCB n. 746 de 16/6/2026, read in full 2026-09-24 from the BCB normativos data, applied to the consolidated IN BCB n. 512/2024 (VersaoNormativo 4) art. 10 and art. 3 par. 14, read the same day. The new wording of art. 10 par. 2 IV and V changes only the list punctuation so that V closes the list; the substance of those two items is unchanged. Written from the text, not from a consolidated version that shows the change, because the BCB's consolidated text had not yet folded it in when read.", "confidence": "high" }, "currency": { "effective_since": "2026-10-01", "effective_to": null, "effective_note": "Drafted 2026-09-24 for change calendar decision 3 from the documents named in basis. Approved 2026-06-16 (IN BCB n. 746/2026, published 2026-06-17); in force 2026-10-01. Until then pix:rule.limits-the-user-can-drive-the-limit-in-both-directions governs.", "source_edition": "IN BCB n. 746 de 16/6/2026, VersaoNormativo 1; IN BCB n. 512/2024, consolidated text, VersaoNormativo 4", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-in-746-2026-limites", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms IN BCB 746/2026 art. 1 gives new wording to IN BCB 512/2024 art. 10 paragraph 2 items IV and V, and art. 2 item I revokes item VI, effective 2026-10-01. The new wording of items IV and V only changes list punctuation so item V closes the list after item VI drops out; the substance of raising or lowering the Pix Automatico and Pix Agendado daily limits and registering payees for a limit of their own is unchanged. Confirms the remaining items I to V of art. 10 paragraph 2 cover the general Pix limit, the withdrawal and change limit, the Pix Automatico and Pix Agendado daily limits, and payee registration, and that art. 3 paragraph 14 lets the general limit be set to zero on request." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:rule.consumer-law-the-limit-panel-must-be-where-the-customer-from-2026", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.limits-the-user-can-drive-the-limit-in-both-directions", "id": "rule.limits-the-user-can-drive-the-limit-in-both-directions", "rail": "pix", "class": "Rule", "name": "The user can drive the limit in both directions", "statement": "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.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-in-512-2024-limites", "section": "arts. 10 caput and par. 2 (incisos as amended by IN BCB n. 629 de 5/6/2025) and 3 par. 14", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:limits by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2025-09-29", "effective_to": "2026-10-01", "effective_note": "Split out of pix:limits by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's. Stops applying 2026-10-01, when IN BCB n. 746 de 16/6/2026 (arts. 1 to 3) takes the contactless item out of the limit panel (IN 512 art. 10 par. 2 VI revoked); the draft successor is pix:rule.limits-the-user-can-drive-the-limit-in-both-directions-from-2026.", "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": "pix:src.bcb-in-512-2024-limites", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:limits, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:mandate.pix-automatico-authorisation", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-the-payer-sets-the-maximum-the-business-sets-its-floor", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.consumer-law-the-limit-panel-must-be-where-the-customer", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.limits-the-user-can-drive-the-limit-in-both-directions-from-2026", "type": "supersedes", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.limits-why-a-bank-may-set-a-limit-at-all", "id": "rule.limits-why-a-bank-may-set-a-limit-at-all", "rail": "pix", "class": "Rule", "name": "Why a bank may set a limit at all", "statement": "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.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "art. 37 caput (wording by Resolucao BCB n. 506/2025)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.pix-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:limits by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2025-09-29", "effective_to": null, "effective_note": "Split out of pix:limits by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 37 caput, wording by Resolucao BCB n. 506/2025, confirms a participant may set value limits only on fraud and anti money laundering and terrorist financing grounds, weighed against the payer's characteristics and profile, and confirms the earlier requirement to benchmark against comparable payment instruments has been removed from the caput." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.limits-withdrawal-and-change-carry-hard-ceilings", "id": "rule.limits-withdrawal-and-change-carry-hard-ceilings", "rail": "pix", "class": "Rule", "name": "Withdrawal and change carry hard ceilings", "statement": "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.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-in-512-2024-limites", "section": "arts. 5 and 6 caput, paragraphs 1, 3, 4 and 5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-saque", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-troco", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:limits by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2025-09-29", "effective_to": null, "effective_note": "Split out of pix:limits by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-in-512-2024-limites", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:limits, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.messages-disputes-are-rest-not-iso", "id": "rule.messages-disputes-are-rest-not-iso", "rail": "pix", "class": "Rule", "name": "Disputes are REST, not ISO", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-manual-operacional-dict-8-5", "section": "sections 10, 10.1, 17 and 20.1.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:messages by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "high" }, "currency": { "effective_since": "2026-06-28", "effective_to": null, "effective_note": "Split out of pix:messages by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-manual-operacional-dict-8-5", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Sections 10, 10.1, 17 and 20.1.1 confirm the DICT REST endpoints createFundsRecovery, createFraudMarker and RefundFundsRecovery, and confirm lowercase domain values including refund_request, scam and mule_account rather than ISO codes." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.messages-pix-automatico-authorization-messages", "id": "rule.messages-pix-automatico-authorization-messages", "rail": "pix", "class": "Rule", "name": "Pix Automatico: authorization messages", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-catalogo-servicos-sfn-vol-vi-5-12", "section": "p. 19", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-automatico", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:messages by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2026-06-28", "effective_to": null, "effective_note": "Split out of pix:messages by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-catalogo-servicos-sfn-vol-vi-5-12", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "The periodic payment authorization messages section confirms pain.009 opens the request, pain.012 confirms and acknowledges at each step including cancellation, and pain.011 cancels, all relayed by the SPI between the two PSPs." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:mandate.pix-automatico-authorisation", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-either-side-may-cancel-the-authorisation", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-three-refusal-families-and-who-raises-them", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.messages-pix-automatico-instruction-messages", "id": "rule.messages-pix-automatico-instruction-messages", "rail": "pix", "class": "Rule", "name": "Pix Automatico: instruction messages", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-catalogo-servicos-sfn-vol-vi-5-12", "section": "p. 20", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-automatico", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:messages by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2026-06-28", "effective_to": null, "effective_note": "Split out of pix:messages by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-catalogo-servicos-sfn-vol-vi-5-12", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "The periodic payment instruction messages section confirms pain.013 from the payee side and pain.014 acknowledging it from the payer side, the payer starting the ordinary scheduled flow on the due date, and camt.055 answered by camt.029 for a pre settlement cancellation sendable by either side." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:mandate.pix-automatico-authorisation", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-a-standing-authorisation-not-a-debit-pull", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-cancelling-one-scheduled-payment", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-three-refusal-families-and-who-raises-them", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.messages-rejection-reasons-live-on-the-pacs-002", "id": "rule.messages-rejection-reasons-live-on-the-pacs-002", "rail": "pix", "class": "Rule", "name": "Rejection reasons live on the pacs.002", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "section": "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", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:messages by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "high" }, "currency": { "effective_since": "2026-06-28", "effective_to": null, "effective_note": "Split out of pix:messages by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "PACS002.xlsx Tabela de Dominios confirms 43 rejection reason codes on StsRsnInf/Rsn/Cd in 5.12.1, each row naming whether the SPI or the receiving participant raises it, and confirms the separate 4 value TxSts status field." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.messages-reporting-payments-that-never-touched-the-spi", "id": "rule.messages-reporting-payments-that-never-touched-the-spi", "rail": "pix", "class": "Rule", "name": "Reporting payments that never touched the SPI", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-catalogo-servicos-sfn-vol-vi-5-12", "section": "pp. 18 and 19", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.settling-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:messages by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2026-06-28", "effective_to": null, "effective_note": "Split out of pix:messages by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-catalogo-servicos-sfn-vol-vi-5-12", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Confirms participants report payments settled in their own systems using trck.002, that camt.025 tells the participant whether the record was stored, and that on a failed store the participant must correct and resend until it succeeds." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.messages-resending-is-safe-by-design", "id": "rule.messages-resending-is-safe-by-design", "rail": "pix", "class": "Rule", "name": "Resending is safe, by design", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-catalogo-servicos-sfn-vol-vi-5-12", "section": "pp. 15, 16 and 18", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:messages by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "high" }, "currency": { "effective_since": "2026-06-28", "effective_to": null, "effective_note": "Split out of pix:messages by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-catalogo-servicos-sfn-vol-vi-5-12", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:messages, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.messages-the-payment-pair", "id": "rule.messages-the-payment-pair", "rail": "pix", "class": "Rule", "name": "The payment pair", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-catalogo-servicos-sfn-vol-vi-5-12", "section": "pp. 14 and 18", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:messages by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2026-06-28", "effective_to": null, "effective_note": "Split out of pix:messages by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-catalogo-servicos-sfn-vol-vi-5-12", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:messages, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.messages-the-return-pair-and-its-four-reasons", "id": "rule.messages-the-return-pair-and-its-four-reasons", "rail": "pix", "class": "Rule", "name": "The return pair, and its four reasons", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "section": "archives spi.5.12.1.zip and spi.5.13.1.zip, PACS004.xlsx domain table for RtrRsnInf/Rsn/Cd", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.devolucao", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:messages by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2026-06-28", "effective_to": null, "effective_note": "Split out of pix:messages by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "PACS004.xlsx Tabela de Dominios confirms exactly four values on RtrRsnInf/Rsn/Cd, MD06, SL02, BE08 and FR01, with the comment column matching each stated meaning." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.messages-the-standard-and-the-envelope", "id": "rule.messages-the-standard-and-the-envelope", "rail": "pix", "class": "Rule", "name": "The standard and the envelope", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-catalogo-servicos-sfn-vol-vi-5-12", "section": "pp. 10 and 11", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.pix-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:messages by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2026-06-28", "effective_to": null, "effective_note": "Split out of pix:messages by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-catalogo-servicos-sfn-vol-vi-5-12", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:messages, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.messages-two-catalogs-alive-at-once", "id": "rule.messages-two-catalogs-alive-at-once", "rail": "pix", "class": "Rule", "name": "Two catalogs alive at once", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-comunicacao-eletronica-de-dados", "section": "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", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "section": "NotasDeVersao.pdf and notasVersaoDiff/NotasVersaoDiff5.13.1v5.12.1.xlsx in spi.5.13.1.zip", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.bcb", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Restated 2026-09-22 from the comunicacaodados page data and from spi.5.13.1.zip, both fetched fresh and read for this record. Every date is off the page's own schedules for versions 5.12 and 5.13; the 93 day gaps are arithmetic on those dates. The archive was opened and listed: it holds NotasDeVersao.pdf, whose contents run back to catalog version 1.0 of 2019-11-14, and a difference spreadsheet against 5.12.1. That a code present only in the newer release is not yet valid is read from the production dates, not stated in terms on the page. Unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2026-06-28", "effective_to": null, "effective_note": "Split out of pix:messages by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's. Corrected 2026-09-22: the record opened by saying a catalog is published roughly six months before the SPI accepts it, which the dates in its own next clause contradict. The comunicacaodados page data was read again: both of the last two gaps are 93 days, about three months, and the statement now says three and adds the homologation dates that sit inside the gap. The record awaits re-validation.", "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": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.messages-two-channels-and-the-first-message-picks-one", "id": "rule.messages-two-channels-and-the-first-message-picks-one", "rail": "pix", "class": "Rule", "name": "Two channels, and the first message picks one", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-catalogo-servicos-sfn-vol-vi-5-12", "section": "pp. 13 and 14", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-agendado", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:messages by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2026-06-28", "effective_to": null, "effective_note": "Split out of pix:messages by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-catalogo-servicos-sfn-vol-vi-5-12", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:messages, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.participants-a-responsible-participant-that-walks-away-owes", "id": "rule.participants-a-responsible-participant-that-walks-away-owes", "rail": "pix", "class": "Rule", "name": "A responsible participant that walks away owes notice too", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "arts. 28 and 29 caput with paragraphs 1 and 2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.responsible-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:participants by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2026-03-05", "effective_to": null, "effective_note": "Split out of pix:participants by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 28 confirms the contract must provide for termination without notice when the contracting participant fails to meet the participation requirements, and art. 29 caput with paragraphs 1 and 2 confirm a 90 day notice for ending service otherwise, a notice period the contract may lengthen." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.participants-direct-or-indirect-is-a-separate-question", "id": "rule.participants-direct-or-indirect-is-a-separate-question", "rail": "pix", "class": "Rule", "name": "Direct or indirect is a separate question", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "section": "art. 2 inciso I and Chapter IV", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-manual-operacional-dict-8-5", "section": "flows in sections 3 to 9, 15, 17 and 20, each written twice for direct and indirect access", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.direct-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.indirect-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:participants by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2026-03-05", "effective_to": null, "effective_note": "Split out of pix:participants by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 2 inciso I defines the SPI and Chapter IV art. 14 confirms the two participation modalities, direct with Conta PI ownership and direct connection, and indirect through a direct participant that acts as settling participant." }, { "source": "pix:src.bcb-manual-operacional-dict-8-5", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Several flows, including sections 17.1.1 and 17.1.2 and section 17.3.1, are each written once for participants with direct DICT access and once for indirect access, confirming DICT access is likewise split into a direct and an indirect path." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.participants-five-roles-and-they-are-not-interchangeable", "id": "rule.participants-five-roles-and-they-are-not-interchangeable", "rail": "pix", "class": "Rule", "name": "Five roles, and they are not interchangeable", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "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)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:participants by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "high" }, "currency": { "effective_since": "2026-03-05", "effective_to": null, "effective_note": "Split out of pix:participants by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:participants, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.participants-how-participants-are-identified-and-where-to", "id": "rule.participants-how-participants-are-identified-and-where-to", "rail": "pix", "class": "Rule", "name": "How participants are identified, and where to find them", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-manual-operacional-dict-8-5", "section": "section 17.3 and its footnote 24 pointing at bcb.gov.br/estabilidadefinanceira/participantespix", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "section": "spi.5.12.1.zip, PACS002.xlsx domain table entries RC09 and RC10 on participant identification", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:participants by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "high" }, "currency": { "effective_since": "2026-03-05", "effective_to": null, "effective_note": "Split out of pix:participants by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-manual-operacional-dict-8-5", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Section 17.3 footnote 24 confirms the BCB publishes the Pix participant list at bcb.gov.br/estabilidadefinanceira/participantespix and points the receiving PSP at it to find the payer PSP's CNPJ for a Pix Automatico reimbursement pacs.008." }, { "source": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "PACS002.xlsx Tabela de Dominios confirms RC09 and RC10 are raised on an invalid or missing ISPB for the payer or receiving participant, confirming ISPB rather than an account routing number is how a participant is identified in SPI messages." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.participants-leaving-takes-90-days-and-does-not-end", "id": "rule.participants-leaving-takes-90-days-and-does-not-end", "rail": "pix", "class": "Rule", "name": "Leaving takes 90 days and does not end responsibility", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "art. 30 caput and paragraphs 1, 2, 3 and 4 (wordings by Resolucoes BCB n. 403/2024 and n. 425 de 16/10/2024)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.pix-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:participants by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2026-03-05", "effective_to": null, "effective_note": "Split out of pix:participants by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:participants, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.participants-payment-institutions-can-join-before-they-are", "id": "rule.participants-payment-institutions-can-join-before-they-are", "rail": "pix", "class": "Rule", "name": "Payment institutions can join before they are fully authorised", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "art. 3 paragraphs 4 and 5 inciso I letters a to d (wordings by Resolucoes BCB n. 403/2024 and n. 429/2024)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.bcb", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:participants by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2026-03-05", "effective_to": null, "effective_note": "Split out of pix:participants by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 3 par. 4, wording by Resolucao BCB n. 429/2024, confirms a payment institution covered by par. 9 becomes part of the Brazilian payment system from the moment it applies to join Pix; par. 5 incisos I letters a to d, wordings by Resolucoes BCB n. 403/2024 and n. 429/2024, confirm the reduced rules it must meet until authorised cover operational and liquidity risk management, cyber security and cloud contracting, anti money laundering controls, and United Nations sanctions procedures." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.participants-somebody-has-to-vouch-for-a-smaller-institution", "id": "rule.participants-somebody-has-to-vouch-for-a-smaller-institution", "rail": "pix", "class": "Rule", "name": "Somebody has to vouch for a smaller institution", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "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)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.responsible-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:participants by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2026-03-05", "effective_to": null, "effective_note": "Split out of pix:participants by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:participants, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.participants-what-a-direct-spi-participant-signs-up-to", "id": "rule.participants-what-a-direct-spi-participant-signs-up-to", "rail": "pix", "class": "Rule", "name": "What a direct SPI participant signs up to", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "section": "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)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.direct-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:participants by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2026-03-05", "effective_to": null, "effective_note": "Split out of pix:participants by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 17 inciso VI confirms the duty to keep systems able to meet the Manual de Tempos times; art. 18 inciso I confirms the duty to tell the BCB immediately of any irregularity, inciso II confirms 24 hour connection every day of the year, and inciso III letters a and b, wording by Resolucao BCB n. 524/2025, confirm maintaining funds for its own and its indirect participants' settlement and watching the Conta PI in real time for atypical or potentially fraudulent movement, stopping processing on suspected compromise." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.participants-who-has-to-join", "id": "rule.participants-who-has-to-join", "rail": "pix", "class": "Rule", "name": "Who has to join", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "art. 3 caput and paragraphs 1, 2 and 3 inciso I (wording by Resolucao BCB n. 429 de 11/11/2024)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.bcb", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:participants by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2026-03-05", "effective_to": null, "effective_note": "Split out of pix:participants by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:participants, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.participants-who-is-allowed-to-be-a-responsible-participant", "id": "rule.participants-who-is-allowed-to-be-a-responsible-participant", "rail": "pix", "class": "Rule", "name": "Who is allowed to be a responsible participant is narrowing", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "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", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.responsible-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:participants by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2026-03-05", "effective_to": null, "effective_note": "Split out of pix:participants by the 2026-09 Orca Core migration; no rule change identified. The line itself dates this from 2026-03-05.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:participants, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.recall-asking-freezes-money-immediately", "id": "rule.recall-asking-freezes-money-immediately", "rail": "pix", "class": "Rule", "name": "Asking freezes money immediately", "statement": "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.", "rests_on": "rule", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-manual-operacional-dict-8-5", "section": "section 20.1.4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "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)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.med", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:recall by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2026-07-01", "effective_to": null, "effective_note": "Split out of pix:recall by the 2026-09 Orca Core migration; no rule change identified. The line itself dates this from 2026-07-01.", "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": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-manual-operacional-dict-8-5", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Section 20.1.4 confirms the receiving participant must freeze the requested amount immediately up to available balance and top the block up as new funds arrive, and confirms several notices on the same payment stack, capped at the transaction value." }, { "source": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 41-D caput inciso II, wording by Resolucao BCB n. 493 de 28/8/2025, confirms the block covers the amount requested or the available balance if smaller; par. 1, wording by Resolucao BCB n. 559 de 23/4/2026 in force from 1/7/2026, confirms the block must be made immediately on receipt of the notice and topped up whenever funds land, up to the requested value or until the case closes." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.recall-for-fraud-the-dict-drives-the-whole-thing", "id": "rule.recall-for-fraud-the-dict-drives-the-whole-thing", "rail": "pix", "class": "Rule", "name": "For fraud, the DICT drives the whole thing", "statement": "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.", "rests_on": "rule", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-manual-operacional-dict-8-5", "section": "section 20 opening paragraphs and graph depth note; section 20.1 stage list I to VI", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.med", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.bcb", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Restated 2026-09-22 from Manual Operacional do DICT 8.5 sections 20 and 20.1, opened and read in full for this record. The six stages of section 20.1 are regrouped here by who acts, the DICT alone or a person at a notified bank, rather than narrated in the manual's stage order; the layer by layer construction of the tracking graph is the section 20 note on graph depth. Unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2026-09-01", "effective_to": null, "effective_note": "Split out of pix:recall by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's. Corrected 2026-09-22: the statement carried over from the fact gave one clause per stage in the order of Manual Operacional do DICT 8.5 section 20.1's stage list, which rule 3 forbids. It has been rewritten from a fresh reading of sections 20 and 20.1, grouped by who acts rather than by stage, and the record awaits re-validation.", "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": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.recall-fraud-marking-is-a-separate-thing-from-asking", "id": "rule.recall-fraud-marking-is-a-separate-thing-from-asking", "rail": "pix", "class": "Rule", "name": "Fraud marking is a separate thing from asking for money", "statement": "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.", "rests_on": "rule", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-manual-operacional-dict-8-5", "section": "section 10 opening text and section 10.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.notificacao-de-infracao", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:recall by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2026-09-01", "effective_to": null, "effective_note": "Split out of pix:recall by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-manual-operacional-dict-8-5", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Section 10 opening text confirms createFundsRecovery and createFraudMarker are the two endpoints that raise infraction notices; section 10.2 confirms createFraudMarker only flags the CPF, CNPJ or key of the marking participant's own customer and asks for no money." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.recall-no-cancellation-no-recall-message", "id": "rule.recall-no-cancellation-no-recall-message", "rail": "pix", "class": "Rule", "name": "No cancellation, no recall message", "statement": "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.", "rests_on": "rule", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "section": "art. 40", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-catalogo-servicos-sfn-vol-vi-5-12", "section": "message chapter pp. 17 to 21 (absence of a recall message)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "pix:rule.finality-there-is-no-sender-cancellation-and-no", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:recall by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the see_also link to the Rule that states the same provision at another scope.", "confidence": "high" }, "currency": { "effective_since": "2026-09-01", "effective_to": null, "effective_note": "Split out of pix:recall by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 40 confirms settlement of a credit order is irrevocable and unconditional once effected." }, { "source": "pix:src.bcb-catalogo-servicos-sfn-vol-vi-5-12", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "The message chapter names no camt.056 and no message that recalls a settled payment; the two cancellation messages the catalog does carry, camt.055 and pain.011, are described elsewhere as working on a future debit or a standing authorization, not a settled payment." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.recall-the-recovering-bank-must-police-its-own-request", "id": "rule.recall-the-recovering-bank-must-police-its-own-request", "rail": "pix", "class": "Rule", "name": "The recovering bank must police its own request", "statement": "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.", "rests_on": "rule", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-manual-operacional-dict-8-5", "section": "sections 20.1.5, 20.1.10 and 20.1.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.med", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:recall by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2026-09-01", "effective_to": null, "effective_note": "Split out of pix:recall by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-manual-operacional-dict-8-5", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Section 20.1.5 confirms the recovering participant must judge the merit of its own customer's claim and cancel where it concludes there is no fraud, even after receiving participants closed their notices; section 20.1.10 confirms cancellation obliges repaying funds already collected to each receiving participant; section 20.1.1 confirms a cancelled case can never be reopened on the same transaction." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.recall-the-request-goes-over-dict-not-over-iso", "id": "rule.recall-the-request-goes-over-dict-not-over-iso", "rail": "pix", "class": "Rule", "name": "The request goes over DICT, not over ISO", "statement": "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.", "rests_on": "rule", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-manual-operacional-dict-8-5", "section": "section 17, opening field table", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.med", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:recall by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2026-09-01", "effective_to": null, "effective_note": "Split out of pix:recall by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-manual-operacional-dict-8-5", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Section 17 opening field table confirms the request names the contested transaction by EndToEndId or RtrId, an amount, one of exactly three reasons, operational_flaw, fraud or pix_automatico, and a free text comments field." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.recall-the-window-to-ask-is-80-days", "id": "rule.recall-the-window-to-ask-is-80-days", "rail": "pix", "class": "Rule", "name": "The window to ask is 80 days", "statement": "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.", "rests_on": "rule", "facet": "recall", "parameters": { "time_window": { "count": 80, "unit": "calendar_day", "from": "settlement_date", "text": "80 days from the contested transaction" } }, "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-manual-operacional-dict-8-5", "section": "section 20.1.1 (the 80 day figure for a pacs.004 applies from 2026-09-01; version 8.4 said 30 days)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.med", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:recall by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: typed parameters and the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2026-09-01", "effective_to": null, "effective_note": "Split out of pix:recall by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-manual-operacional-dict-8-5", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Section 20.1.1 confirms the DICT checks an 80 day window on opening, for either an original pacs.008 or a return pacs.004, confirms only one Recuperacao de Valores may ever be opened per transaction even after a cancellation, and confirms none may be opened where a standalone infraction notice already contested the same transaction." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.recall-two-grounds-it-never-covers", "id": "rule.recall-two-grounds-it-never-covers", "rail": "pix", "class": "Rule", "name": "Two grounds it never covers", "statement": "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.", "rests_on": "rule", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "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)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.med", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:recall by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2026-09-01", "effective_to": null, "effective_note": "Split out of pix:recall by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 41-B par. 1 incisos I and II, wording by Resolucao BCB n. 167/2021, confirm the MED excludes disputes about the underlying deal and funds that reached a good faith third party; par. 3, wording by Resolucao BCB n. 403 de 22/7/2024, confirms operational failure excludes a payment the customer correctly initiated for the amount actually credited." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.recall-what-the-special-mechanism-is-for", "id": "rule.recall-what-the-special-mechanism-is-for", "rail": "pix", "class": "Rule", "name": "What the special mechanism is for", "statement": "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.", "rests_on": "rule", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "art. 41-B caput incisos I, II and III (wording by Resolucao BCB n. 402 de 22/7/2024)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.med", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:recall by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2026-09-01", "effective_to": null, "effective_note": "Split out of pix:recall by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 41-B caput incisos I to III, wording by Resolucao BCB n. 402 de 22/7/2024, confirm the three grounds: fraud, IT failure at either participant, and a faulty Pix Automatico payment, whether from the payer PSP's own error, no live authorization, or a payment departing from the authorized terms." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:rule.automatico-a-faulty-payment-is-refunded-within-24-hours", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.recall-who-actually-sends-the-money-back", "id": "rule.recall-who-actually-sends-the-money-back", "rail": "pix", "class": "Rule", "name": "Who actually sends the money back", "statement": "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.", "rests_on": "rule", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "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)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.med", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:recall by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2026-09-01", "effective_to": null, "effective_note": "Split out of pix:recall by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 41-C caput confirms every MED return is executed by the receiving participant; current inciso I, wording by Resolucao BCB n. 269/2022, confirms it may act on its own where it identified the conduct, where the failure was in its own systems, or after a precautionary hold it now judges well founded; current inciso II, wording by Resolucao BCB n. 402/2024, confirms the usual trigger is a request the payer's participant sends through the DICT." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.refund-accepting-even-with-no-money-is-expected", "id": "rule.refund-accepting-even-with-no-money-is-expected", "rail": "pix", "class": "Rule", "name": "Accepting even with no money is expected", "statement": "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.", "rests_on": "rule", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-manual-operacional-dict-8-5", "section": "section 20.1.5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.med", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:refund by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2026-09-01", "effective_to": null, "effective_note": "Split out of pix:refund by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-manual-operacional-dict-8-5", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Section 20.1.5 confirms a receiving participant that concludes the transaction was part of the fraud dispersion must accept the notice even with no balance, so that later transactions in the chain can reach the subsequent return stage." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.refund-everything-else-presupposes-funds", "id": "rule.refund-everything-else-presupposes-funds", "rail": "pix", "class": "Rule", "name": "Everything else presupposes funds", "statement": "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.", "rests_on": "rule", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "arts. 41-A caput inciso I and 41-A par. 1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.devolucao", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:refund by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2026-09-01", "effective_to": null, "effective_note": "Split out of pix:refund by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 41-A caput inciso I confirms every return presupposes sufficient funds in the receiving account, and par. 1, added by Resolucao BCB n. 402 de 22/7/2024, confirms that presupposition does not apply to the faulty Pix Automatico ground of art. 41-B caput inciso III." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.refund-four-different-ways-the-money-travels", "id": "rule.refund-four-different-ways-the-money-travels", "rail": "pix", "class": "Rule", "name": "Four different ways the money travels", "statement": "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.", "rests_on": "rule", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-manual-operacional-dict-8-5", "section": "sections 20.1.6 and 17.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "section": "PACS004.xlsx domain table for BE08 and FR01", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.med", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:refund by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2026-09-01", "effective_to": null, "effective_note": "Split out of pix:refund by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-manual-operacional-dict-8-5", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:refund, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.refund-grounds-a-receiving-bank-may-give-for-paying", "id": "rule.refund-grounds-a-receiving-bank-may-give-for-paying", "rail": "pix", "class": "Rule", "name": "Grounds a receiving bank may give for paying nothing", "statement": "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.", "rests_on": "rule", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-manual-operacional-dict-8-5", "section": "section 17, closing field table and the paragraphs that follow it", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.med", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:refund by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2026-09-01", "effective_to": null, "effective_note": "Split out of pix:refund by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-manual-operacional-dict-8-5", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:refund, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:rule.decision-points-whether-to-honour-a-return-request-at-all", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:rule.refund-how-much-each-bank-has-to-pay-back", "id": "rule.refund-how-much-each-bank-has-to-pay-back", "rail": "pix", "class": "Rule", "name": "How much each bank has to pay back", "statement": "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.", "rests_on": "rule", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-manual-operacional-dict-8-5", "section": "section 20.1.6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.med", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:refund by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2026-09-01", "effective_to": null, "effective_note": "Split out of pix:refund by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-manual-operacional-dict-8-5", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:refund, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.refund-money-must-be-unblocked-at-only-three-moments", "id": "rule.refund-money-must-be-unblocked-at-only-three-moments", "rail": "pix", "class": "Rule", "name": "Money must be unblocked at only three moments", "statement": "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.", "rests_on": "rule", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-manual-operacional-dict-8-5", "section": "section 20.1.7", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.med", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:refund by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2026-09-01", "effective_to": null, "effective_note": "Split out of pix:refund by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-manual-operacional-dict-8-5", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:refund, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.refund-rejecting-the-refund-does-not-undo-the-fraud", "id": "rule.refund-rejecting-the-refund-does-not-undo-the-fraud", "rail": "pix", "class": "Rule", "name": "Rejecting the refund does not undo the fraud mark", "statement": "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.", "rests_on": "rule", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-manual-operacional-dict-8-5", "section": "section 17 and section 20.1.5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "art. 78-G par. unico (wording by Resolucao BCB n. 425 de 16/10/2024)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.notificacao-de-infracao", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:refund by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2026-09-01", "effective_to": null, "effective_note": "Split out of pix:refund by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-manual-operacional-dict-8-5", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Section 17 and section 20.1.5 confirm a participant may reject a return request even after accepting the infraction notice that came before it, and that on rejection the key and user stay marked as fraud because the mark follows from accepting the notice, not from paying." }, { "source": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 78-G paragrafo unico, wording by Resolucao BCB n. 425 de 16/10/2024, confirms an accepted infraction notice generates a fraud suspicion mark in the DICT on the receiving user's Pix keys and CPF or CNPJ, independent of any later return decision." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.refund-the-72-hour-clock-on-the-return-stage", "id": "rule.refund-the-72-hour-clock-on-the-return-stage", "rail": "pix", "class": "Rule", "name": "The 72 hour clock on the return stage", "statement": "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.", "rests_on": "rule", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-manual-operacional-dict-8-5", "section": "section 20.1.6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.med", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:refund by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2026-09-01", "effective_to": null, "effective_note": "Split out of pix:refund by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-manual-operacional-dict-8-5", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:refund, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.refund-the-operational-failure-route-is-narrower-than", "id": "rule.refund-the-operational-failure-route-is-narrower-than", "rail": "pix", "class": "Rule", "name": "The operational failure route is narrower than it sounds", "statement": "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.", "rests_on": "rule", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-manual-operacional-dict-8-5", "section": "section 17.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.med", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:refund by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from. The detail line of pix:decision-points that restated it was merged into it by the 2026-09 Orca Core migration under section 19 of docs/orca-core-v0-proposal.md. That line cited the same documents, at: Manual Operacional do DICT, version 8.5, section 17.1.", "confidence": "high" }, "currency": { "effective_since": "2026-09-01", "effective_to": null, "effective_note": "Split out of pix:refund by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-manual-operacional-dict-8-5", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Section 17.1 confirms an operational failure return excludes a payment correctly initiated by the payer for the amount actually credited, gives duplicated payments, a wrong amount and money sent without payer confirmation as examples, lists non applicable near misses including a wrong key, a duplicate manual payment and statement or reconciliation failures, and confirms the receiving participant rejects a non qualifying request with invalid_request." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.return-a-return-travels-on-the-fast-channel-and-is", "id": "rule.return-a-return-travels-on-the-fast-channel-and-is", "rail": "pix", "class": "Rule", "name": "A return travels on the fast channel and is idempotent", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-catalogo-servicos-sfn-vol-vi-5-12", "section": "transmission channels chapter p. 14, idempotency chapter pp. 15 and 16, and money transfer messages p. 18", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.devolucao", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:return by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2021-11-16", "effective_to": null, "effective_note": "Split out of pix:return by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-catalogo-servicos-sfn-vol-vi-5-12", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "The transmission channels chapter confirms a devolucao pacs.004 and its pacs.002 responses always travel on the primary channel, and the idempotency chapter confirms a 24 hour window keyed on the pacs.004 IdOperacao that returns the earlier answer on a resend." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.return-funds-must-actually-be-there", "id": "rule.return-funds-must-actually-be-there", "rail": "pix", "class": "Rule", "name": "Funds must actually be there", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "arts. 41-A caput inciso I and 41-A paragraphs 1 and 2 (introduced by Resolucao BCB n. 402 de 22/7/2024)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.devolucao", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:return by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2021-11-16", "effective_to": null, "effective_note": "Split out of pix:return by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 41-A caput inciso I confirms an ordinary return presupposes sufficient funds; par. 1 confirms that presupposition is switched off for the faulty Pix Automatico ground, and par. 2 confirms the payer PSP must in that case return the full amount to its own customer using its own funds." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.return-partial-and-repeated-returns", "id": "rule.return-partial-and-repeated-returns", "rail": "pix", "class": "Rule", "name": "Partial and repeated returns", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "art. 40 par. 2 (wording from 2021-11-16, Resolucao BCB n. 103/2021)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.devolucao", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:return by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2021-11-16", "effective_to": null, "effective_note": "Split out of pix:return by the 2026-09 Orca Core migration; no rule change identified. The line itself dates this from 2021-11-16.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:return, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.return-pix-saque-and-pix-troco-a-different-starter-and", "id": "rule.return-pix-saque-and-pix-troco-a-different-starter-and", "rail": "pix", "class": "Rule", "name": "Pix Saque and Pix Troco: a different starter and a one hour clock", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "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)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.devolucao", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.withdrawal-facilitator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.withdrawal-agent", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-saque", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-troco", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:return by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2021-11-16", "effective_to": null, "effective_note": "Split out of pix:return by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:return, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.return-pix-troco-needs-two-returns", "id": "rule.return-pix-troco-needs-two-returns", "rail": "pix", "class": "Rule", "name": "Pix Troco needs two returns", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "arts. 41 par. 3 and 41-A caput inciso II", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "section": "PACS004.xlsx SL02 comment", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.devolucao", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-troco", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:return by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2021-11-16", "effective_to": null, "effective_note": "Split out of pix:return by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 41 par. 3 confirms a Pix Troco return needs a specific transaction for the cash portion, kept apart from the purchase amount, and par. 4 confirms the cash portion carries a one hour clock; art. 41-A caput inciso II, wording by Resolucao BCB n. 167/2021, confirms only the cash portion sits outside the 90 day rule." }, { "source": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "PACS004.xlsx Tabela de Dominios confirms the SL02 comment ties that code to Pix Saque or Pix Troco returns and confirms MD06 is the general receiving user request code used for the purchase leg." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.return-returns-do-not-consume-the-payers-limits", "id": "rule.return-returns-do-not-consume-the-payers-limits", "rail": "pix", "class": "Rule", "name": "Returns do not consume the payer's limits", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-in-512-2024-limites", "section": "art. 3 par. 12", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.devolucao", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:return by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2021-11-16", "effective_to": null, "effective_note": "Split out of pix:return by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-in-512-2024-limites", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 3 par. 12 confirms returns under Regulamento Chapter XI Section I must not count against the value limits a participant sets for the payer." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.return-the-90-day-window", "id": "rule.return-the-90-day-window", "rail": "pix", "class": "Rule", "name": "The 90 day window", "statement": "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.", "rests_on": "rule", "facet": "return", "parameters": { "time_window": { "count": 90, "unit": "calendar_day", "from": "settlement_date", "text": "90 days from the day of the original payment" } }, "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "art. 41-A caput inciso II (wording by Resolucao BCB n. 167 de 24/11/2021)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.devolucao", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:return by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: typed parameters and the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2021-11-16", "effective_to": null, "effective_note": "Split out of pix:return by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:return, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.return-the-reason-code-an-operator-will-see", "id": "rule.return-the-reason-code-an-operator-will-see", "rail": "pix", "class": "Rule", "name": "The reason code an operator will see", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "section": "archive spi.5.12.1.zip, PACS004.xlsx domain table for RtrRsnInf/Rsn/Cd, and the same table in spi.5.13.1.zip", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.devolucao", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:return by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2021-11-16", "effective_to": null, "effective_note": "Split out of pix:return by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "PACS004.xlsx Tabela de Dominios confirms the four pacs.004 return reasons and their meanings, MD06 for a receiving user request, SL02 for withdrawal and change, BE08 and FR01 for the special mechanism grounds." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.return-what-the-receiving-users-bank-then-does", "id": "rule.return-what-the-receiving-users-bank-then-does", "rail": "pix", "class": "Rule", "name": "What the receiving user's bank then does", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "arts. 41 caput and 41 par. 1 (wording from 2021-11-16 and inclusion by Resolucao BCB n. 135/2021)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.devolucao", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:return by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2021-11-16", "effective_to": null, "effective_note": "Split out of pix:return by the 2026-09 Orca Core migration; no rule change identified. The line itself dates this from 2021-11-16.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 41 caput confirms the receiving customer states the return amount to their participant, and par. 1 confirms the participant debits that amount from the customer's account only after the customer's authorization, remits it to the payer's participant, and states the reason for the return." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.return-who-may-start-one", "id": "rule.return-who-may-start-one", "rail": "pix", "class": "Rule", "name": "Who may start one", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "arts. 40 caput and 40 par. 1 (wording from 2021-11-16, Resolucao BCB n. 103/2021)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "pix:exc.devolucao", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.receiving-user", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:return by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2021-11-16", "effective_to": null, "effective_note": "Split out of pix:return by the 2026-09 Orca Core migration; no rule change identified. The line itself dates this from 2021-11-16.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:return, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.settlement-balance-checks-need-not-follow-arrival-order", "id": "rule.settlement-balance-checks-need-not-follow-arrival-order", "rail": "pix", "class": "Rule", "name": "Balance checks need not follow arrival order", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "section": "arts. 36 par. 3 and 38 par. unico", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.bcb", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:settlement by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2022-04-01", "effective_to": null, "effective_note": "Split out of pix:settlement by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 36 par. 3 confirms checking available balance in the issuing participant's Conta PI need not follow the chronological order in which orders arrived, and art. 38 par. unico confirms settlement itself need not follow that order either." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.settlement-credit-push-only-national-currency-immediate", "id": "rule.settlement-credit-push-only-national-currency-immediate", "rail": "pix", "class": "Rule", "name": "Credit push only, national currency, immediate", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "section": "arts. 32 and 33, with art. 33 par. unico", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:settlement by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2022-04-01", "effective_to": null, "effective_note": "Split out of pix:settlement by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:settlement, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.settlement-liquidity-for-the-conta-pi", "id": "rule.settlement-liquidity-for-the-conta-pi", "rail": "pix", "class": "Rule", "name": "Liquidity for the Conta PI", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "section": "art. 18 inciso III", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "arts. 43 and 44", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.direct-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:settlement by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2022-04-01", "effective_to": null, "effective_note": "Split out of pix:settlement by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 18 inciso III confirms a direct participant must manage its Conta PI 24 hours a day every day, maintaining funds for its own settlements and those of the indirect participants it settles for." }, { "source": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 43 confirms the BCB offers a liquidity provision service to direct SPI participants, and art. 44 confirms clearing houses and settlement service providers may offer their own liquidity mechanisms in addition, within the rules of their own systems and the SPI Regulamento." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.settlement-service-levels-not-just-deadlines", "id": "rule.settlement-service-levels-not-just-deadlines", "rail": "pix", "class": "Rule", "name": "Service levels, not just deadlines", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-manual-de-tempos-do-pix-7-0", "section": "sections 4.1.1.1, 4.1.1.2 and 4.1.2.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.pix-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:settlement by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2022-04-01", "effective_to": null, "effective_note": "Split out of pix:settlement by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-manual-de-tempos-do-pix-7-0", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Sections 4.1.1.1, 4.1.1.2 and 4.1.2.1 confirm the payer participant's 0.9 second P50 and 1.5 second P95 to create the pacs.008, the receiving side's 1.4 second P50 and 2.3 second P95 to authorize, and the payer's end to end experience at 6.0 seconds P50 and 10.0 seconds P99." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.settlement-settlement-outside-the-spi", "id": "rule.settlement-settlement-outside-the-spi", "rail": "pix", "class": "Rule", "name": "Settlement outside the SPI", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "arts. 33 par. unico and 34", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-manual-de-tempos-do-pix-7-0", "section": "sections 1.3 and 1.4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.settling-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:settlement by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from. The detail line of pix:finality that restated it was merged into it by the 2026-09 Orca Core migration under section 19 of docs/orca-core-v0-proposal.md. That line cited the same documents, at: Regulamento Pix, arts. 33 par. unico and 34; Manual de Tempos do Pix 7.0, sections 1.3 and 1.4.", "confidence": "high" }, "currency": { "effective_since": "2022-04-01", "effective_to": null, "effective_note": "Split out of pix:settlement by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 33 par. unico confirms two participants sharing one settling participant settle between themselves in that settling participant's own systems, and art. 34 confirms two end users of the same participant settle in that participant's own systems." }, { "source": "pix:src.bcb-manual-de-tempos-do-pix-7-0", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Section 1.3 confirms payments settled outside the SPI still carry the 40 second or 45 minute limits by channel, and section 1.4 confirms they must be reported to the BCB within 30 days of settlement." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.settlement-step-one-the-spi-blocks-the-sending-banks-funds", "id": "rule.settlement-step-one-the-spi-blocks-the-sending-banks-funds", "rail": "pix", "class": "Rule", "name": "Step one: the SPI blocks the sending bank's funds", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "section": "art. 36 caput and paragraphs 1 and 2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.bcb", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:settlement by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2022-04-01", "effective_to": null, "effective_note": "Split out of pix:settlement by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:settlement, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.settlement-step-three-the-balance-swap-is-settlement", "id": "rule.settlement-step-three-the-balance-swap-is-settlement", "rail": "pix", "class": "Rule", "name": "Step three: the balance swap is settlement", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "section": "arts. 38 caput, 39 and 40 paragraphs 1 and 2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.bcb", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:settlement by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2022-04-01", "effective_to": null, "effective_note": "Split out of pix:settlement by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:settlement, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.settlement-step-two-the-receiving-bank-confirms-it-can-take", "id": "rule.settlement-step-two-the-receiving-bank-confirms-it-can-take", "rail": "pix", "class": "Rule", "name": "Step two: the receiving bank confirms it can take the payment", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "section": "art. 37 caput and par. unico", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.receiver-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:settlement by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2022-04-01", "effective_to": null, "effective_note": "Split out of pix:settlement by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:settlement, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.settlement-the-banks-own-authorization-step-comes-first", "id": "rule.settlement-the-banks-own-authorization-step-comes-first", "rail": "pix", "class": "Rule", "name": "The bank's own authorization step comes first", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "art. 36 caput and par. 1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.payer-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:settlement by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2022-04-01", "effective_to": null, "effective_note": "Split out of pix:settlement by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 36 caput confirms authorization means the payer's participant completed security checks, found sufficient balance and blocked the amount to start settlement through the SPI, and par. 1 confirms only finding sufficient balance is required, with no block, when the payment settles inside the participant's own systems." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.settlement-two-message-channels-two-clocks", "id": "rule.settlement-two-message-channels-two-clocks", "rail": "pix", "class": "Rule", "name": "Two message channels, two clocks", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-catalogo-servicos-sfn-vol-vi-5-12", "section": "transmission channels chapter, pp. 13 and 14", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-manual-de-tempos-do-pix-7-0", "section": "sections 1.1 and 1.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "applies_to", "to": "pix:txn.pix-agendado", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:rule.finality-how-fast-that-has-to-happen", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:settlement by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from and the see_also link to the Rule that states the same provision at another scope.", "confidence": "high" }, "currency": { "effective_since": "2022-04-01", "effective_to": null, "effective_note": "Split out of pix:settlement by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-manual-de-tempos-do-pix-7-0", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Sections 1.1 and 1.2 confirm the 40 second primary channel deadline and the 45 minute secondary channel deadline, the secondary channel carrying only Pix Agendado and scheduled Pix Cobranca." }, { "source": "pix:src.bcb-catalogo-servicos-sfn-vol-vi-5-12", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "The transmission channels chapter confirms the initiating pacs.008 fixes the channel for every later message of the operation and states a pacs.004 return always travels on the primary channel; the payment priority type table confirms PAGAGD marks the secondary channel." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:rule.settlement-what-the-spi-is", "id": "rule.settlement-what-the-spi-is", "rail": "pix", "class": "Rule", "name": "What the SPI is", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "section": "art. 2 inciso I, with art. 31", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "pix:role.bcb", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of pix:settlement by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. Added by the migration from the line's own words, and unchecked: the links other than sourced_from.", "confidence": "high" }, "currency": { "effective_since": "2022-04-01", "effective_to": null, "effective_note": "Split out of pix:settlement by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from pix:settlement, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:src.bcb-catalogo-servicos-sfn-vol-vi-5-12", "id": "src.bcb-catalogo-servicos-sfn-vol-vi-5-12", "rail": "pix", "class": "RuleSource", "name": "Catalogo de Servicos do SFN, Volume VI, Pagamentos Instantaneos, versao 5.12, dated 2026-03-27", "summary": "The message catalog for Pix: the ISO 20022 subset and its envelope, date and time handling, the two transmission channels, idempotency, and the message chapter that lists every message the SPI carries.", "publisher": "Banco Central do Brasil (Deinf)", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/Catalogo_de_Servicos_do_SFN_Volume_VI_Versao_512.pdf", "source_class": "authoritative_primary", "kind": "message_catalog", "edition": "versao 5.12, dated 2026-03-27, in SPI production from 2026-06-28", "access": "open", "consulted_on": "2026-09-18", "relations": [], "basis": { "sources": "Described by the 2026-09 Orca Core migration from the citations and checks of pix:finality, pix:hours, pix:messages, pix:recall, pix:return and pix:settlement, which name it; the URL was confirmed to resolve on 2026-09-22 with a matching content type, and the document was not re-read for this record.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by the 2026-09 Orca Core migration from the pix rail fact citations. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "versao 5.12, dated 2026-03-27, in SPI production from 2026-06-28", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "pix:rule.finality-there-is-no-sender-cancellation-and-no", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.hours-messages-are-in-utc-rules-speak-brasilia", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.messages-pix-automatico-authorization-messages", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.messages-pix-automatico-instruction-messages", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.messages-reporting-payments-that-never-touched-the-spi", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.messages-resending-is-safe-by-design", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.messages-the-payment-pair", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.messages-the-standard-and-the-envelope", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.messages-two-channels-and-the-first-message-picks-one", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.recall-no-cancellation-no-recall-message", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.return-a-return-travels-on-the-fast-channel-and-is", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.settlement-two-message-channels-two-clocks", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "pix:src.bcb-comunicacao-eletronica-de-dados", "id": "src.bcb-comunicacao-eletronica-de-dados", "rail": "pix", "class": "RuleSource", "name": "Comunicacao eletronica de dados page on bcb.gov.br", "summary": "The BCB page that indexes the SFN catalogs and their message definition archives and gives each version's publication and production dates.", "publisher": "Banco Central do Brasil", "url": "https://www.bcb.gov.br/estabilidadefinanceira/comunicacaodados", "source_class": "public_primary", "kind": "web_page", "edition": "live page, read through its public page data endpoint 2026-09-18", "access": "open", "consulted_on": "2026-09-18", "relations": [], "basis": { "sources": "Described by the 2026-09 Orca Core migration from the citations and checks of pix:messages, which name it; the URL was confirmed to resolve on 2026-09-22 with a matching content type, and the document was not re-read for this record.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by the 2026-09 Orca Core migration from the pix rail fact citations. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "live page, read through its public page data endpoint 2026-09-18", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "pix:codeset.pain012-authorisation-rejection-reasons-from-2026", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "pix:codeset.pain014-instruction-errors-from-2026", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.messages-two-catalogs-alive-at-once", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "id": "src.bcb-definicoes-detalhadas-mensagens-spi", "rail": "pix", "class": "RuleSource", "name": "Definicoes detalhadas das mensagens do Catalogo do SPI, archives spi.5.12.1.zip and spi.5.13.1.zip", "summary": "The per message spreadsheets, schemas and release notes behind the catalog. The domain tables hold the controlled field values, among them the pacs.004 return reasons and the pacs.002 rejection reasons.", "publisher": "Banco Central do Brasil (Deinf)", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Catalogos/spi.5.12.1.zip", "source_class": "authoritative_primary", "kind": "message_definitions", "edition": "spi.5.12.1.zip dated 2026-03-27 (SPI production 2026-06-28) and spi.5.13.1.zip dated 2026-07-24 (SPI production 2026-10-25)", "access": "open", "consulted_on": "2026-09-18", "relations": [], "basis": { "sources": "Described by the 2026-09 Orca Core migration from the citations and checks of pix:messages, pix:participants, pix:refund and pix:return, which name it; the URL was confirmed to resolve on 2026-09-22 with a matching content type, and the document was not re-read for this record.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by the 2026-09 Orca Core migration from the pix rail fact citations. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "spi.5.12.1.zip dated 2026-03-27 (SPI production 2026-06-28) and spi.5.13.1.zip dated 2026-07-24 (SPI production 2026-10-25)", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "pix:codeset.pain011-cancellation-reasons", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:codeset.pain012-authorisation-rejection-reasons-from-2026", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:codeset.pain012-authorisation-rejection-reasons", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:codeset.pain014-instruction-errors-from-2026", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:codeset.pain014-instruction-errors", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-a-pending-request-lapses-after-30-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-either-side-may-cancel-the-authorisation", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-five-recurrence-periods", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-four-journeys-to-an-authorisation", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-instructions-go-2-to-10-days-ahead", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-journey-3-needs-the-first-payment-to-settle", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-retries-on-later-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-the-payers-bank-schedules-within-2-hours-or-refuses", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-three-refusal-families-and-who-raises-them", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-who-may-offer-and-who-may-collect", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.messages-rejection-reasons-live-on-the-pacs-002", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.messages-the-return-pair-and-its-four-reasons", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.messages-two-catalogs-alive-at-once", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.participants-how-participants-are-identified-and-where-to", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.refund-four-different-ways-the-money-travels", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.return-pix-troco-needs-two-returns", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.return-the-reason-code-an-operator-will-see", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "pix:src.bcb-in-512-2024-limites", "id": "src.bcb-in-512-2024-limites", "rail": "pix", "class": "RuleSource", "name": "Instrucao Normativa BCB n. 512/2024, consolidated text, VersaoNormativo 4", "summary": "The procedure the BCB sets for value limits on Pix: the night ceiling, the criteria that replaced the TED peg, the in app limit panel, the timing of cuts and increases, the withdrawal and change ceilings, and the note appended to the published text on what kind of instrument the Pix rulebook is.", "publisher": "Banco Central do Brasil", "url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Instrução%20Normativa%20BCB&numero=512", "source_class": "authoritative_primary", "kind": "normative_instruction", "edition": "consolidated text, VersaoNormativo 4, amendments listed through Instrucao Normativa BCB n. 746 de 18/6/2026", "access": "open", "consulted_on": "2026-09-18", "relations": [], "basis": { "sources": "Described by the 2026-09 Orca Core migration from the citations and checks of pix:consumer-law, pix:decision-points, pix:hours, pix:liability, pix:limits and pix:return, which name it; the URL was confirmed to resolve on 2026-09-22 with a matching content type, and the document was not re-read for this record.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by the 2026-09 Orca Core migration from the pix rail fact citations. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "consolidated text, VersaoNormativo 4, amendments listed through Instrucao Normativa BCB n. 746 de 18/6/2026", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "pix:rule.consumer-law-the-limit-panel-must-be-where-the-customer-from-2026", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.consumer-law-the-limit-panel-must-be-where-the-customer", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.consumer-law-the-night-ceiling-is-the-single-most-concrete", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.decision-points-whether-to-raise-a-customers-limit", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.hours-the-night-period-is-a-value-rule-not-a-closing", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.liability-what-the-bcb-says-the-rulebook-is", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.limits-contactless-and-initiation-without-redirection-from-2026", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.limits-contactless-and-initiation-without-redirection", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.limits-cuts-are-immediate-increases-are-slow-on-purpose", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.limits-limits-an-operator-will-not-see-in-a-return", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.limits-the-day-limit-is-no-longer-pegged-to-ted", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.limits-the-night-limit-for-person-to-person", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.limits-the-user-can-drive-the-limit-in-both-directions-from-2026", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.limits-the-user-can-drive-the-limit-in-both-directions", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.limits-withdrawal-and-change-carry-hard-ceilings", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.return-returns-do-not-consume-the-payers-limits", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "id": "src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "rail": "pix", "class": "RuleSource", "name": "Instrucao Normativa BCB n. 513/2024, operational procedures for Pix Automatico, Pix Agendado and Pix Cobranca, consolidated version 5.0", "summary": "The BCB's operational instruction for the three scheduled products. For Pix Automatico it is the governing text: there is no separate Pix Automatico manual. It fixes the recurrence periods, the life of a pending authorisation request, when a collection instruction may be sent, when the payer's bank must refuse it, the settlement window and the retries on the day and on later days, the cancellation cut-offs, and the checks a receiving bank runs on a business before offering it Pix Automatico. For Pix Agendado and scheduled due date charges it fixes the settlement window, the evening retry, month-end dates and the cancellation cut-off.", "publisher": "Banco Central do Brasil (Decem)", "url": "https://www.bcb.gov.br/api/conteudo/app/normativos/exibenormativo?p1=Instru%C3%A7%C3%A3o%20Normativa%20BCB&p2=513", "source_class": "authoritative_primary", "kind": "regulation", "edition": "version 5.0, 17 articles including art. 15-A, amended by IN BCB n. 614/2025, n. 634/2025 and n. 743/2026; not revoked", "access": "open", "consulted_on": "2026-09-22", "relations": [], "basis": { "sources": "Fetched on 2026-09-22 with a plain compressed GET from the BCB normativos data endpoint, no login and no terms, and read in full in Portuguese. The consolidated text shows superseded wording beside current wording, each tagged with the amending instruction; records built on it cite the current wording.", "confidence": "high" }, "currency": { "effective_since": "2024-08-30", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day.", "source_edition": "version 5.0 as served 2026-09-22", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "pix:mandate.pix-automatico-authorisation", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.agendado-a-repeat-date-the-month-lacks-moves-to-the-1st", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.agendado-and-scheduled-charges-settle-00-to-08-with-an-evening-retry", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-a-faulty-payment-is-refunded-within-24-hours", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-a-pending-request-lapses-after-30-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-a-settlement-error-allows-a-same-day-resend", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-cancelling-one-scheduled-payment", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-cancelling-the-authorisation-stops-what-is-scheduled", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-five-recurrence-periods", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-four-journeys-to-an-authorisation", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-instructions-go-2-to-10-days-ahead", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-retries-on-later-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-settlement-date-is-the-due-date", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-settles-between-00-and-08-with-an-evening-retry", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-the-pacs008-is-marked-auto", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-the-payer-sets-the-maximum-the-business-sets-its-floor", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-the-payers-bank-schedules-within-2-hours-or-refuses", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-three-refusal-families-and-who-raises-them", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-who-may-offer-and-who-may-collect", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:txn.pix-agendado", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "pix:txn.pix-automatico", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "pix:src.bcb-in-746-2026-limites", "id": "src.bcb-in-746-2026-limites", "rail": "pix", "class": "RuleSource", "name": "Instrucao Normativa BCB n. 746/2026, amending the Pix value limits", "summary": "A short amending instruction from the BCB's Decem. From 2026-10-01 it takes the R$500.00 per payment ceiling off contactless Pix and off payments started through shared initiation without redirection, by revoking arts. 16-A and 16-C of IN BCB n. 512/2024, drops the contactless item from the limit panel a bank must offer (art. 10 par. 2 VI revoked, items IV and V reworded to close the list), and removes that item from the art. 12 caput on increases. It sets no replacement figure.", "publisher": "Banco Central do Brasil (Decem)", "url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Instru%C3%A7%C3%A3o%20Normativa%20BCB&numero=746", "source_class": "authoritative_primary", "kind": "normative_instruction", "edition": "IN BCB n. 746 de 16/6/2026, published in the DOU of 17/6/2026, Secao 1, p. 457, VersaoNormativo 1, not revoked; in force 2026-10-01 (art. 3)", "access": "open", "consulted_on": "2026-09-24", "relations": [], "basis": { "sources": "Read in full on 2026-09-24 from the data the BCB normativos page loads, https://www.bcb.gov.br/api/conteudo/app/normativos/exibenormativo?p1=Instru%C3%A7%C3%A3o%20Normativa%20BCB&p2=746, with a plain compressed GET: the heading, arts. 1 to 3, the referencias metadata and the appended NOTA. The consolidated IN BCB n. 512/2024 (VersaoNormativo 4) was read the same day and lists this instrument among its updates but does not yet show its wording inline.", "confidence": "high" }, "currency": { "effective_since": "2026-10-01", "effective_to": null, "effective_note": "A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on. The instrument was signed 2026-06-16 and published 2026-06-17; it takes effect 2026-10-01.", "source_edition": "IN BCB n. 746 de 16/6/2026, DOU of 17/6/2026, VersaoNormativo 1", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "pix:rule.consumer-law-the-limit-panel-must-be-where-the-customer-from-2026", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.limits-contactless-and-initiation-without-redirection-from-2026", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.limits-the-user-can-drive-the-limit-in-both-directions-from-2026", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "pix:src.bcb-manual-de-tempos-do-pix-7-0", "id": "src.bcb-manual-de-tempos-do-pix-7-0", "rail": "pix", "class": "RuleSource", "name": "Manual de Tempos do Pix, versao 7.0", "summary": "The maximum times of the Pix arrangement: the two settlement clocks and the two for payments settled outside the SPI, the fraud hold window and its cancellation duty, and the service level indicators participants are measured on.", "publisher": "Banco Central do Brasil", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/IX_ManualdeTemposdoPix.pdf", "source_class": "authoritative_primary", "kind": "operational_manual", "edition": "versao 7.0, PDF created 2026-02-04, revision history entries 2025-11-23 and 2026-02-02", "access": "open", "consulted_on": "2026-09-17", "relations": [], "basis": { "sources": "Described by the 2026-09 Orca Core migration from the citations and checks of pix:decision-points, pix:finality, pix:hours and pix:settlement, which name it; the URL was confirmed to resolve on 2026-09-22 with a matching content type, and the document was not re-read for this record.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by the 2026-09 Orca Core migration from the pix rail fact citations. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "versao 7.0, PDF created 2026-02-04, revision history entries 2025-11-23 and 2026-02-02", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "pix:rule.decision-points-whether-to-hold-a-payment-before-it-settles", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.finality-how-fast-that-has-to-happen", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.finality-one-cancellation-window-does-exist-before", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.finality-there-is-no-sender-cancellation-and-no", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.hours-availability-is-measured-and-has-a-floor", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.hours-payment-clocks-40-seconds-or-45-minutes", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.hours-the-fraud-hold-runs-on-business-hours", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.settlement-service-levels-not-just-deadlines", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.settlement-settlement-outside-the-spi", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.settlement-two-message-channels-two-clocks", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:txn.pix-agendado", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:src.bcb-manual-operacional-dict-8-5", "id": "src.bcb-manual-operacional-dict-8-5", "rail": "pix", "class": "RuleSource", "name": "Manual Operacional do Diretorio de Identificadores de Contas Transacionais (DICT), versao 8.5, effective 2026-09-01 and 2026-10-26", "summary": "The operating manual for the DICT: key management, the fraud marking and infraction notice flows, the return request flow and its closing reasons, and the funds recovery stages with their clocks.", "publisher": "Banco Central do Brasil", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/versoes_futuras/X_ManualOperacionaldoDICT-versao8-5.pdf", "source_class": "authoritative_primary", "kind": "operational_manual", "edition": "versao 8.5, published under the versoes_futuras path, effective 2026-09-01 and 2026-10-26", "access": "open", "consulted_on": "2026-09-18", "relations": [], "basis": { "sources": "Described by the 2026-09 Orca Core migration from the citations and checks of pix:consumer-law, pix:decision-points, pix:messages, pix:participants, pix:recall and pix:refund, which name it; the URL was confirmed to resolve on 2026-09-22 with a matching content type, and the document was not re-read for this record.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by the 2026-09 Orca Core migration from the pix rail fact citations. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "versao 8.5, published under the versoes_futuras path, effective 2026-09-01 and 2026-10-26", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "pix:rule.consumer-law-a-complaint-can-start-a-recovery", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.decision-points-where-the-dict-decides-instead-of-a-person", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.decision-points-whether-to-accept-an-infraction-notice-about", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.decision-points-whether-to-cancel-a-recovery-you-opened", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.decision-points-whether-to-honour-a-return-request-at-all", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.decision-points-whether-to-open-a-recovery-on-the-customers-word", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.messages-disputes-are-rest-not-iso", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.participants-direct-or-indirect-is-a-separate-question", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.participants-how-participants-are-identified-and-where-to", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.recall-asking-freezes-money-immediately", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.recall-for-fraud-the-dict-drives-the-whole-thing", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.recall-fraud-marking-is-a-separate-thing-from-asking", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.recall-the-recovering-bank-must-police-its-own-request", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.recall-the-request-goes-over-dict-not-over-iso", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.recall-the-window-to-ask-is-80-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.refund-accepting-even-with-no-money-is-expected", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.refund-four-different-ways-the-money-travels", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.refund-grounds-a-receiving-bank-may-give-for-paying", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.refund-how-much-each-bank-has-to-pay-back", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.refund-money-must-be-unblocked-at-only-three-moments", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.refund-rejecting-the-refund-does-not-undo-the-fraud", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.refund-the-72-hour-clock-on-the-return-stage", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.refund-the-operational-failure-route-is-narrower-than", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "id": "src.bcb-manual-padroes-iniciacao-pix-2-10-0", "rail": "pix", "class": "RuleSource", "name": "Manual de Padroes para Iniciacao do Pix, version 2.10.0", "summary": "The part of the Regulamento that sets how a Pix is started from data prepared in advance: the static, dynamic and composite QR code standards (BR Code), Pix Copia e Cola, the payload of an immediate charge and of a charge with a due date with its interest, fine, discount and rebate fields, the transaction identifier rules, and, in its annexes, the API Pix business concepts, the calculation of due date charges and the Pix Automatico recurrence, request and recurring charge objects with their states.", "publisher": "Banco Central do Brasil", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II_ManualdePadroesparaIniciacaodoPix.pdf", "source_class": "authoritative_primary", "kind": "manual", "edition": "version 2.10.0, revision history entry dated 2026-08-19, 123 pages", "access": "open", "consulted_on": "2026-09-22", "relations": [], "basis": { "sources": "Fetched on 2026-09-22 with a plain compressed GET, no login and no terms; the text layer was extracted with python3 and pypdf and read in Portuguese. The document is marked Publico.", "confidence": "high" }, "currency": { "effective_since": "2026-08-19", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day.", "source_edition": "version 2.10.0", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "pix:mandate.pix-automatico-authorisation", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-a-cycle-on-a-day-the-month-lacks", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-cancelling-one-scheduled-payment", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-either-side-may-cancel-the-authorisation", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-five-recurrence-periods", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-four-journeys-to-an-authorisation", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-journey-3-needs-the-first-payment-to-settle", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-retries-on-later-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-what-the-payer-may-edit-and-when-it-bites", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.cobranca-a-charge-takes-one-payment-and-an-identifier-is-never-reused", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.cobranca-a-due-date-charge-rolls-to-the-payers-next-business-day", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.cobranca-a-static-code-leaves-reconciliation-to-the-receiver", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.cobranca-an-immediate-charge-lives-24-hours-by-default", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.cobranca-static-dynamic-and-composite-qr-codes", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.cobranca-the-payees-bank-computes-the-final-amount", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:state.charge-active", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:state.charge-concluded", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:state.charge-removed-by-the-psp", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:state.charge-removed-by-the-receiver", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:state.recurrence-approved", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:state.recurrence-cancelled", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:state.recurrence-created", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:state.recurrence-expired", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:state.recurrence-rejected", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:txn.pix-cobranca", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:src.bcb-requisitos-minimos-experiencia-usuario-7-3", "id": "src.bcb-requisitos-minimos-experiencia-usuario-7-3", "rail": "pix", "class": "RuleSource", "name": "Requisitos Minimos para a Experiencia do Usuario, version 7.3", "summary": "The part of the Regulamento that turns the user experience duties into numbered mandatory and recommended items for the apps of natural person customers. Chapter 15 covers Pix Automatico from the payer's side: the menu, pending, active and historical authorisations, what the payer may edit, cancelling an authorisation or one scheduled payment, the journey that pairs a first payment with the authorisation, and the notifications the payer's bank must send.", "publisher": "Banco Central do Brasil", "url": "https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/IV_RequisitosMinimosparaExperienciadoUsuario.pdf", "source_class": "authoritative_primary", "kind": "manual", "edition": "version 7.3 of December 2025, 164 pages; version 7.4 announced on the cover as in force from 2027-03-01", "access": "open", "consulted_on": "2026-09-22", "relations": [], "basis": { "sources": "Fetched on 2026-09-22 with a plain compressed GET, no login and no terms; the text layer was extracted with python3 and pypdf (the 2026-09-17 finding that it could not be read was a tooling gap) and chapter 15, pages 82 to 103, was read in Portuguese. The document states that reproduction is permitted with attribution for non-commercial use; Orca still cites and does not reproduce it.", "confidence": "high" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day.", "source_edition": "version 7.3 of December 2025; the day is not given", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "pix:mandate.pix-automatico-authorisation", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-a-pending-request-lapses-after-30-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-a-pre-approved-credit-line-may-fund-it", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-cancelling-one-scheduled-payment", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-cancelling-the-authorisation-stops-what-is-scheduled", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-either-side-may-cancel-the-authorisation", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-journey-3-needs-the-first-payment-to-settle", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-settlement-date-is-the-due-date", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-settles-between-00-and-08-with-an-evening-retry", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-the-payer-sets-the-maximum-the-business-sets-its-floor", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-what-an-authorisation-must-state", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-what-the-payer-may-edit-and-when-it-bites", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:state.recurrence-cancelled", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "id": "src.bcb-resolucao-1-2020-regulamento-pix", "rail": "pix", "class": "RuleSource", "name": "Resolucao BCB n. 1/2020 and annexed Regulamento Pix, consolidated text, VersaoNormativo 41", "summary": "The instrument that institutes Pix and the Regulamento annexed to it: who must join, the five scheme roles, the duties to reject and to freeze, returns, the special return mechanism, fraud risk management, dispute routing and enforcement.", "publisher": "Banco Central do Brasil", "url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20BCB&numero=1", "source_class": "authoritative_primary", "kind": "regulation", "edition": "consolidated text, VersaoNormativo 41, amendments listed through Resolucao BCB n. 559 de 23/4/2026", "access": "open", "consulted_on": "2026-09-18", "relations": [], "basis": { "sources": "Described by the 2026-09 Orca Core migration from the citations and checks of pix:consumer-law, pix:decision-points, pix:finality, pix:hours, pix:liability, pix:limits, pix:participants, pix:recall, pix:refund, pix:return and pix:settlement, which name it; the URL was confirmed to resolve on 2026-09-22 with a matching content type, and the document was not re-read for this record.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by the 2026-09 Orca Core migration from the pix rail fact citations. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "consolidated text, VersaoNormativo 41, amendments listed through Resolucao BCB n. 559 de 23/4/2026", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "pix:rail.pix", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "pix:mandate.pix-automatico-authorisation", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.agendado-and-scheduled-charges-settle-00-to-08-with-an-evening-retry", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-a-pre-approved-credit-line-may-fund-it", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-a-standing-authorisation-not-a-debit-pull", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-either-side-may-cancel-the-authorisation", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-four-journeys-to-an-authorisation", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-journey-3-needs-the-first-payment-to-settle", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-retries-on-later-days", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-the-payer-sets-the-maximum-the-business-sets-its-floor", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-what-an-authorisation-must-state", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-what-the-payer-may-edit-and-when-it-bites", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.automatico-who-may-offer-and-who-may-collect", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.cobranca-immediate-and-due-date-charges", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.consumer-law-a-complaint-can-start-a-recovery", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.consumer-law-a-fee-rule-and-a-disclosure-rule", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.consumer-law-a-freeze-the-customer-never-has-to-ask-for", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.consumer-law-the-rulebook-obliges-a-good-experience-in-terms", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.decision-points-is-the-suspicion-well-founded", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.decision-points-what-to-do-at-the-end-of-72-hours", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.decision-points-whether-to-accept-an-infraction-notice-about", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.decision-points-whether-to-freeze-money-as-it-lands", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.decision-points-whether-to-lift-a-block-on-a-flagged-account", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.decision-points-whether-to-open-a-recovery-on-the-customers-word", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.finality-fourth-layer-finality-does-not-settle-who-bears", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.finality-second-layer-a-return-is-a-new-payment-not-a", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.finality-third-layer-the-money-can-be-frozen-the-instant", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.hours-messages-are-in-utc-rules-speak-brasilia", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.hours-the-dict-never-closes-either", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.hours-what-a-bank-must-offer-its-own-customers-is", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.liability-a-bad-rejection-makes-the-receiving-bank", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.liability-access-devices-must-be-registered", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.liability-an-accepted-notice-shuts-the-account-out-of-pix", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.liability-fraud-risk-management-is-a-stated-obligation", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.liability-non-compliance-is-a-supervision-matter", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.liability-pix-automatico-the-payers-bank-pays-first", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.liability-the-duty-to-freeze-on-arrival", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.liability-the-duty-to-reject-on-both-sides", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.liability-the-hold-is-no-longer-limited-to-individuals", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.liability-the-requesting-participant-owns-the-med-return", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.liability-where-disagreements-go", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.limits-a-ceiling-aimed-at-the-weakest-technical-link", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.limits-no-limit-on-how-many", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.limits-why-a-bank-may-set-a-limit-at-all", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.participants-a-responsible-participant-that-walks-away-owes", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.participants-five-roles-and-they-are-not-interchangeable", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.participants-leaving-takes-90-days-and-does-not-end", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.participants-payment-institutions-can-join-before-they-are", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.participants-somebody-has-to-vouch-for-a-smaller-institution", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.participants-who-has-to-join", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.participants-who-is-allowed-to-be-a-responsible-participant", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.recall-asking-freezes-money-immediately", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.recall-two-grounds-it-never-covers", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.recall-what-the-special-mechanism-is-for", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.recall-who-actually-sends-the-money-back", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.refund-everything-else-presupposes-funds", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.refund-rejecting-the-refund-does-not-undo-the-fraud", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.return-funds-must-actually-be-there", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.return-partial-and-repeated-returns", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.return-pix-saque-and-pix-troco-a-different-starter-and", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.return-pix-troco-needs-two-returns", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.return-the-90-day-window", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.return-what-the-receiving-users-bank-then-does", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.return-who-may-start-one", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.settlement-liquidity-for-the-conta-pi", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.settlement-settlement-outside-the-spi", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.settlement-the-banks-own-authorization-step-comes-first", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:txn.pix-agendado", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "pix:txn.pix-automatico", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:txn.pix-cobranca", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "pix:src.bcb-resolucao-19-2020-tarifas", "id": "src.bcb-resolucao-19-2020-tarifas", "rail": "pix", "class": "RuleSource", "name": "Resolucao BCB n. 19/2020, consolidated text, VersaoNormativo 3", "summary": "What a Pix participant may and may not charge an end user for, and where the amount charged has to be shown. It carries the charging rules the Regulamento leaves out, and covers payment initiation service fees in the same instrument.", "publisher": "Banco Central do Brasil", "url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20BCB&numero=19", "source_class": "authoritative_primary", "kind": "regulation", "edition": "consolidated text, VersaoNormativo 3, in force from 2020-11-03, as amended by Resolucao BCB n. 30/2020 and Resolucao BCB n. 136/2021 with effect from 2021-11-01; not revoked", "access": "open", "consulted_on": "2026-09-22", "relations": [], "basis": { "sources": "Described 2026-09-22 from the consolidated text itself, fetched from the BCB normativos page data with a plain compressed GET and read in full: 8 articles plus arts. 4-A, 7-A and 7-B, across four chapters. Publication in the DOU of 2020-10-02 and the amendment list are the record's own metadata fields.", "confidence": "high" }, "currency": { "effective_since": "2020-11-03", "effective_to": null, "effective_note": "Created 2026-09-22 so that pix:rule.consumer-law-a-fee-rule-and-a-disclosure-rule can cite the fee instrument by its own record rather than inside another source's section text. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "consolidated text, VersaoNormativo 3, latest amendment Resolucao BCB n. 136 de 2/9/2021 with effect from 2021-11-01", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "pix:rule.consumer-law-a-fee-rule-and-a-disclosure-rule", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "id": "src.bcb-resolucao-195-2022-regulamento-spi", "rail": "pix", "class": "RuleSource", "name": "Regulamento do Sistema de Pagamentos Instantaneos (SPI), anexo a Resolucao BCB n. 195/2022, consolidated text, VersaoNormativo 6", "summary": "The regulation of the settlement system behind Pix: what the SPI is, its hours, the Conta PI, the blocking and balance swap steps, irrevocability, and the duties of a direct participant.", "publisher": "Banco Central do Brasil", "url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20BCB&numero=195", "source_class": "authoritative_primary", "kind": "regulation", "edition": "consolidated text, VersaoNormativo 6, latest amendment listed Resolucao BCB n. 554 de 24/3/2026", "access": "open", "consulted_on": "2026-09-18", "relations": [], "basis": { "sources": "Described by the 2026-09 Orca Core migration from the citations and checks of pix:finality, pix:hours, pix:limits, pix:participants, pix:recall and pix:settlement, which name it; the URL was confirmed to resolve on 2026-09-22 with a matching content type, and the document was not re-read for this record.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by the 2026-09 Orca Core migration from the pix rail fact citations. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "consolidated text, VersaoNormativo 6, latest amendment listed Resolucao BCB n. 554 de 24/3/2026", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "pix:rail.pix", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.finality-the-moment-of-finality", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.finality-the-system-presumes-the-order-is-good", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.hours-an-instant-payment-is-defined-as-always", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.hours-availability-is-measured-and-has-a-floor", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.hours-banks-must-be-open-too", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.hours-messages-are-in-utc-rules-speak-brasilia", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.hours-the-spi-never-closes", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.limits-the-network-sets-no-ceiling", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.participants-direct-or-indirect-is-a-separate-question", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.participants-what-a-direct-spi-participant-signs-up-to", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.recall-no-cancellation-no-recall-message", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.settlement-balance-checks-need-not-follow-arrival-order", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.settlement-credit-push-only-national-currency-immediate", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.settlement-liquidity-for-the-conta-pi", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.settlement-step-one-the-spi-blocks-the-sending-banks-funds", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.settlement-step-three-the-balance-swap-is-settlement", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.settlement-step-two-the-receiving-bank-confirms-it-can-take", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "pix:rule.settlement-what-the-spi-is", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "pix:src.cmn-resolucao-4949-2021", "id": "src.cmn-resolucao-4949-2021", "rail": "pix", "class": "RuleSource", "name": "Resolucao CMN n. 4.949/2021, consolidated text, VersaoNormativo 2", "summary": "The general principles and procedures a financial institution must follow with its customers, and the scope article that decides which institutions they reach.", "publisher": "Conselho Monetario Nacional", "url": "https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolução%20CMN&numero=4949", "source_class": "authoritative_primary", "kind": "regulation", "edition": "consolidated text, VersaoNormativo 2, wording of art. 1 par. 1 from 2024-03-01 by Resolucao CMN n. 5.117/2024", "access": "open", "consulted_on": "2026-09-17", "relations": [], "basis": { "sources": "Described by the 2026-09 Orca Core migration from the citations and checks of pix:consumer-law, which name it; the URL was confirmed to resolve on 2026-09-22 with a matching content type, and the document was not re-read for this record.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by the 2026-09 Orca Core migration from the pix rail fact citations. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "consolidated text, VersaoNormativo 2, wording of art. 1 par. 1 from 2024-03-01 by Resolucao CMN n. 5.117/2024", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "pix:rule.consumer-law-the-general-customer-protection-resolution-has-a", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "pix:state.charge-active", "id": "state.charge-active", "rail": "pix", "class": "LifecycleState", "name": "Pix charge: active", "summary": "The charge exists and can be paid. While it is active the business may change it, and a fresh read of its QR code shows the new terms, or remove it.", "terminal": false, "money_moved": "no", "visible_as": "API Pix charge status ATIVA", "relations": [ { "type": "precedes", "to": "pix:state.charge-concluded", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "precedes", "to": "pix:state.charge-removed-by-the-receiver", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "precedes", "to": "pix:state.charge-removed-by-the-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "pix:rule.cobranca-a-charge-takes-one-payment-and-an-identifier-is-never-reused", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "section": "Annex I section 5.1 item I and its footnote 79, sections 2.7.1.1 and 2.7.1.2, and Annex I sections 6.5.2 and 6.5.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Manual de Padroes para Iniciacao do Pix 2.10.0 Annex I section 5.1 item I, sections 2.7.1.1 and 2.7.1.2, and Annex I sections 6.5.2 and 6.5.3, read 2026-09-22.", "confidence": "high" }, "currency": { "effective_since": "Unknown: the states predate version 2.10.0 and their dates were not traced", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. Pix Cobranca entered the Regulamento on 2020-11-03 (Resolucao BCB n. 30/2020); the manual details read are those of version 2.10.0. The states are the API Pix states the manual defines for the charge object, immediate or with a due date.", "source_edition": "Manual de Padroes para Iniciacao do Pix version 2.10.0 of 2026-08-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms at Annex I section 5.1 item I that ATIVA marks a charge generated and ready to be paid, and at section 6.5.3 that an active charge may be changed by the receiving user with a fresh QR code read showing the updated terms, and at 6.5.2 that it may be removed" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:state.charge-concluded", "id": "state.charge-concluded", "rail": "pix", "class": "LifecycleState", "name": "Pix charge: concluded", "summary": "A Pix carrying the charge's transaction identifier has been received. The charge now accepts no other payment and can be neither changed nor removed. It says the charge was paid, not that the debt behind it is settled.", "terminal": true, "money_moved": "yes", "visible_as": "API Pix charge status CONCLUIDA", "relations": [ { "type": "governed_by", "to": "pix:rule.cobranca-a-charge-takes-one-payment-and-an-identifier-is-never-reused", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "section": "Annex I section 5.1 item I and its footnote 79, sections 2.7.1.1 and 2.7.1.2, and Annex I sections 6.5.2 and 6.5.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Manual de Padroes para Iniciacao do Pix 2.10.0 Annex I section 5.1 item I, sections 2.7.1.1 and 2.7.1.2, and Annex I sections 6.5.2 and 6.5.3, read 2026-09-22. The manual calls this status final in terms.", "confidence": "high" }, "currency": { "effective_since": "Unknown: the states predate version 2.10.0 and their dates were not traced", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. Pix Cobranca entered the Regulamento on 2020-11-03 (Resolucao BCB n. 30/2020); the manual details read are those of version 2.10.0. The states are the API Pix states the manual defines for the charge object, immediate or with a due date.", "source_edition": "Manual de Padroes para Iniciacao do Pix version 2.10.0 of 2026-08-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms at Annex I section 5.1 item I and footnote 79 that CONCLUIDA marks a charge a matching Pix has settled, accepting no other payment, and that it does not indicate the underlying obligation is settled, and at section 6.5.3 that a concluded charge can neither be changed nor removed because that status is final" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:state.charge-active", "type": "precedes", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:state.charge-removed-by-the-psp", "id": "state.charge-removed-by-the-psp", "rail": "pix", "class": "LifecycleState", "name": "Pix charge: removed by the payee's bank", "summary": "The payee's bank removed the charge itself. The manual names the state without saying on what grounds a bank does this or whether it can be reversed; terminal here is [Inference].", "terminal": true, "money_moved": "no", "visible_as": "API Pix charge status REMOVIDO_PELO_PSP", "relations": [ { "type": "governed_by", "to": "pix:rule.cobranca-a-charge-takes-one-payment-and-an-identifier-is-never-reused", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "section": "Annex I section 5.1 item I and its footnote 79, sections 2.7.1.1 and 2.7.1.2, and Annex I sections 6.5.2 and 6.5.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Manual de Padroes para Iniciacao do Pix 2.10.0 Annex I section 5.1 item I, sections 2.7.1.1 and 2.7.1.2, and Annex I sections 6.5.2 and 6.5.3, read 2026-09-22. terminal is [Inference]; the grounds for removal by the bank are not given.", "confidence": "low" }, "currency": { "effective_since": "Unknown: the states predate version 2.10.0 and their dates were not traced", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. Pix Cobranca entered the Regulamento on 2020-11-03 (Resolucao BCB n. 30/2020); the manual details read are those of version 2.10.0. The states are the API Pix states the manual defines for the charge object, immediate or with a due date.", "source_edition": "Manual de Padroes para Iniciacao do Pix version 2.10.0 of 2026-08-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms at Annex I section 5.1 item I that REMOVIDO_PELO_PSP marks a charge the receiving participant itself asked removed, with no stated grounds or reversal path in the text read" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:state.charge-active", "type": "precedes", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:state.charge-removed-by-the-receiver", "id": "state.charge-removed-by-the-receiver", "rail": "pix", "class": "LifecycleState", "name": "Pix charge: removed by the receiver", "summary": "The business asked its bank to remove the charge, for example because the customer gave up the purchase. A payer who reads the code afterwards must be told the charge was deleted. The manual calls only the concluded status final and gives no way to reactivate a removed charge; terminal here is [Inference].", "terminal": true, "money_moved": "no", "visible_as": "API Pix charge status REMOVIDO_PELO_USUARIO_RECEBEDOR; the payer's app says the charge was deleted", "relations": [ { "type": "governed_by", "to": "pix:rule.cobranca-a-charge-takes-one-payment-and-an-identifier-is-never-reused", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "section": "Annex I section 5.1 item I and its footnote 79, sections 2.7.1.1 and 2.7.1.2, and Annex I sections 6.5.2 and 6.5.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Manual de Padroes para Iniciacao do Pix 2.10.0 Annex I section 5.1 item I, sections 2.7.1.1 and 2.7.1.2, and Annex I sections 6.5.2 and 6.5.3, read 2026-09-22. terminal is [Inference].", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the states predate version 2.10.0 and their dates were not traced", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. Pix Cobranca entered the Regulamento on 2020-11-03 (Resolucao BCB n. 30/2020); the manual details read are those of version 2.10.0. The states are the API Pix states the manual defines for the charge object, immediate or with a due date.", "source_edition": "Manual de Padroes para Iniciacao do Pix version 2.10.0 of 2026-08-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms at Annex I section 5.1 item I that REMOVIDO_PELO_USUARIO_RECEBEDOR marks a charge the receiving user asked removed, and at section 6.5.2 that a payer who still reads the code must be told the charge was deleted, and that only the CONCLUIDA status is final, so removed here is [Inference] as the record flags" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:state.charge-active", "type": "precedes", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:state.recurrence-approved", "id": "state.recurrence-approved", "rail": "pix", "class": "LifecycleState", "name": "Pix Automatico recurrence: approved by the payer", "summary": "The payer has authorised the recurrence, so the business's bank may now send collection instructions under it. On the messages it is confirmed by the payer (CFDB). Only in this state does the payer's bank schedule a collection; an instruction against any other status is refused (pain.014 MSUC).", "terminal": false, "money_moved": "no", "visible_as": "API Pix recurrence status APROVADA; pain.012 MandateStatus CFDB; listed under Active authorisations in the payer's app", "relations": [ { "type": "precedes", "to": "pix:state.recurrence-expired", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "precedes", "to": "pix:state.recurrence-cancelled", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "pix:rule.automatico-the-payers-bank-schedules-within-2-hours-or-refuses", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "section": "Annex I section 5.1 item VII, and Annex IV sections 2.1.4 and 2.1.6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Manual de Padroes para Iniciacao do Pix 2.10.0 Annex I section 5.1 item VII and Annex IV section 2.1, read 2026-09-22. The message statuses that match (PDNG, CFDB, CCLD) are in the pain.012 domain table of spi.5.12.1.zip, read the same day. The MSUC refusal is from the pain.014 domain table of the same archive.", "confidence": "high" }, "currency": { "effective_since": "2025-06-16", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. The states are the API Pix states the Manual de Padroes para Iniciacao do Pix defines for the recurrence object.", "source_edition": "Manual de Padroes para Iniciacao do Pix version 2.10.0 of 2026-08-19; SPI message definitions spi.5.12.1.zip (in production since 2026-06-28) and spi.5.13.1.zip (production from 2026-10-25), domain tables", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms at Annex I section 5.1 item VII that APROVADA marks a recurrence the payer accepted, at Annex V section 3.2 that CFDB is the message value once the payer's permission is communicated, and that pain.014 code MSUC rejects a scheduling attempt against an inconsistent recurrence status" }, { "source": "pix:src.bcb-definicoes-detalhadas-mensagens-spi", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms in the PAIN014.xlsx domain table that MSUC (UnconfirmedMandateStatus) rejects a scheduling instruction whenever the recurrence status is not CFDB" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:state.recurrence-created", "type": "precedes", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:state.recurrence-cancelled", "id": "state.recurrence-cancelled", "rail": "pix", "class": "LifecycleState", "name": "Pix Automatico recurrence: cancelled", "summary": "The payer, the business or either bank cancelled the recurrence, with one of the eleven pain.011 reasons. Payments already scheduled after the cancellation day are dropped. The cancellation cannot be undone.", "terminal": true, "money_moved": "no", "visible_as": "API Pix recurrence status CANCELADA, with who asked and why under encerramento.cancelamento; pain.012 MandateStatus CCLD", "relations": [ { "type": "governed_by", "to": "pix:rule.automatico-either-side-may-cancel-the-authorisation", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "pix:rule.automatico-cancelling-the-authorisation-stops-what-is-scheduled", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "section": "Annex I section 5.1 item VII, and Annex IV sections 2.1.4 and 2.1.6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-requisitos-minimos-experiencia-usuario-7-3", "section": "chapter 15 item 27", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Manual de Padroes para Iniciacao do Pix 2.10.0 Annex I section 5.1 item VII and Annex IV section 2.1, read 2026-09-22. The message statuses that match (PDNG, CFDB, CCLD) are in the pain.012 domain table of spi.5.12.1.zip, read the same day. That it cannot be undone is the Requisitos Minimos 7.3 chapter 15 item 27, read the same day.", "confidence": "high" }, "currency": { "effective_since": "2025-06-16", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. The states are the API Pix states the Manual de Padroes para Iniciacao do Pix defines for the recurrence object.", "source_edition": "Manual de Padroes para Iniciacao do Pix version 2.10.0 of 2026-08-19; SPI message definitions spi.5.12.1.zip (in production since 2026-06-28) and spi.5.13.1.zip (production from 2026-10-25), domain tables; Requisitos Minimos para a Experiencia do Usuario version 7.3 of December 2025; its cover announces version 7.4 in force from 2027-03-01", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms at Annex I section 5.1 item VII that CANCELADA marks a recurrence cancelled by the payer or the receiving user, at Annex V section 3.3 the eleven pain.011 cancellation reasons, and at Requisitos Minimos 7.3 chapter 15 item 27 that a cancellation is final and only that day's scheduled payment survives" }, { "source": "pix:src.bcb-requisitos-minimos-experiencia-usuario-7-3", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms chapter 15 item 27 that cancelling an authorisation cannot be undone and drops every scheduled payment except one already set for that same day" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:state.recurrence-approved", "type": "precedes", "status": "draft", "effective_status": "draft" }, { "from": "pix:state.recurrence-created", "type": "precedes", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:state.recurrence-created", "id": "state.recurrence-created", "rail": "pix", "class": "LifecycleState", "name": "Pix Automatico recurrence: created", "summary": "The business has created the recurrence at its bank and the payer has not yet authorised it. In journey 1 a confirmation request is on its way to, or waiting at, the payer's bank; in journeys 2 to 4 it waits behind a QR code. On the messages it is pending (PDNG).", "terminal": false, "money_moved": "no", "visible_as": "API Pix recurrence status CRIADA; pain.012 MandateStatus PDNG; the payer sees it under Pending authorisations in journey 1", "relations": [ { "type": "precedes", "to": "pix:state.recurrence-approved", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "precedes", "to": "pix:state.recurrence-rejected", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "precedes", "to": "pix:state.recurrence-cancelled", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "pix:rule.automatico-four-journeys-to-an-authorisation", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "pix:rule.automatico-a-pending-request-lapses-after-30-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "section": "Annex I section 5.1 item VII, and Annex IV sections 2.1.4 and 2.1.6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Manual de Padroes para Iniciacao do Pix 2.10.0 Annex I section 5.1 item VII and Annex IV section 2.1, read 2026-09-22. The message statuses that match (PDNG, CFDB, CCLD) are in the pain.012 domain table of spi.5.12.1.zip, read the same day.", "confidence": "high" }, "currency": { "effective_since": "2025-06-16", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. The states are the API Pix states the Manual de Padroes para Iniciacao do Pix defines for the recurrence object.", "source_edition": "Manual de Padroes para Iniciacao do Pix version 2.10.0 of 2026-08-19; SPI message definitions spi.5.12.1.zip (in production since 2026-06-28) and spi.5.13.1.zip (production from 2026-10-25), domain tables", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms at Annex I section 5.1 item VII that CRIADA marks a recurrence the receiving user created and not yet accepted by the payer, and at Annex V section 3.2 that PDNG is the message value for a recurrence awaiting the payer's journey 1 confirmation" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "pix:state.recurrence-expired", "id": "state.recurrence-expired", "rail": "pix", "class": "LifecycleState", "name": "Pix Automatico recurrence: expired", "summary": "The recurrence's end date has passed, so no further collections may be scheduled under it. A recurrence with no end date never reaches this state.", "terminal": true, "money_moved": "no", "visible_as": "API Pix recurrence status EXPIRADA", "relations": [ { "type": "governed_by", "to": "pix:rule.automatico-what-an-authorisation-must-state", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "section": "Annex I section 5.1 item VII, and Annex IV sections 2.1.4 and 2.1.6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Manual de Padroes para Iniciacao do Pix 2.10.0 Annex I section 5.1 item VII and Annex IV section 2.1, read 2026-09-22. The message statuses that match (PDNG, CFDB, CCLD) are in the pain.012 domain table of spi.5.12.1.zip, read the same day. terminal is [Inference]: the manual defines no transition out of it.", "confidence": "medium" }, "currency": { "effective_since": "2025-06-16", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. The states are the API Pix states the Manual de Padroes para Iniciacao do Pix defines for the recurrence object.", "source_edition": "Manual de Padroes para Iniciacao do Pix version 2.10.0 of 2026-08-19; SPI message definitions spi.5.12.1.zip (in production since 2026-06-28) and spi.5.13.1.zip (production from 2026-10-25), domain tables", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms at Annex I section 5.1 item VII that EXPIRADA marks a recurrence whose end date has passed, and Annex IV section 3.1 that a recurrence with no end date never reaches this state" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:state.recurrence-approved", "type": "precedes", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:state.recurrence-rejected", "id": "state.recurrence-rejected", "rail": "pix", "class": "LifecycleState", "name": "Pix Automatico recurrence: rejected", "summary": "The payer refused a journey 1 request, or the payer's bank refused it, for instance because the account does not exist or the bank does not offer the product. It happens only in journey 1. The manual gives no way back from it; a business that still wants the authorisation creates a new recurrence [Inference].", "terminal": true, "money_moved": "no", "visible_as": "API Pix recurrence status REJEITADA, with the reason under encerramento.rejeicao", "relations": [ { "type": "governed_by", "to": "pix:rule.automatico-a-pending-request-lapses-after-30-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "section": "Annex I section 5.1 item VII, and Annex IV sections 2.1.4 and 2.1.6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Manual de Padroes para Iniciacao do Pix 2.10.0 Annex I section 5.1 item VII and Annex IV section 2.1, read 2026-09-22. The message statuses that match (PDNG, CFDB, CCLD) are in the pain.012 domain table of spi.5.12.1.zip, read the same day. terminal is [Inference]: the manual defines no transition out of it.", "confidence": "medium" }, "currency": { "effective_since": "2025-06-16", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day. The states are the API Pix states the Manual de Padroes para Iniciacao do Pix defines for the recurrence object.", "source_edition": "Manual de Padroes para Iniciacao do Pix version 2.10.0 of 2026-08-19; SPI message definitions spi.5.12.1.zip (in production since 2026-06-28) and spi.5.13.1.zip (production from 2026-10-25), domain tables", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms at Annex I section 5.1 item VII that REJEITADA marks a recurrence the payer refused, occurring only in journey 1, and at Annex IV section 3.1 that this status has no path back" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:state.recurrence-created", "type": "precedes", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:txn.pix-agendado", "id": "txn.pix-agendado", "rail": "pix", "class": "TransactionType", "name": "Pix Agendado (scheduled Pix)", "summary": "A Pix the payer sets up now for a later date, once or as a repeating series. Until that date the order waits inside the payer's bank and the balance is untouched; then it runs as an ordinary Pix. On the day, the bank sends it between 00:00 and 08:00 if the balance and the payer's limit allow; if money was short or the send failed for an operational reason it tries again at least once between 18:00 and 21:00, and if only the limit was short it tells the payer. Before sending one addressed by Pix key it looks the key up again and refuses the payment when the key is gone or now leads to someone else. The payer can cancel until 23:59 the day before. A repeating date the month lacks (29 to 31) moves to the 1st of the next month. The order travels on the SPI's secondary channel (pacs.008 with PAGAGD), where the time limit is 45 minutes rather than the 40 seconds of the primary channel. Banks with accounts for natural persons must offer both single and repeating schedules.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "arts. 8 to 10", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "section": "arts. 12 to 14 and 17 I", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-manual-de-tempos-do-pix-7-0", "section": "sections 1.2 and 1.3, footnote 1", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Regulamento Pix arts. 8 to 10 (consolidated version 41) and IN BCB n. 513/2024 arts. 12 to 14 and 17, both read in Portuguese on 2026-09-23 from the BCB normativos data endpoint; Manual de Tempos do Pix 7.0 sections 1.1 to 1.3 with footnote 1, read the same day. Holding the order without touching the balance is Regulamento art. 9; the retry and the key check at send are art. 9 pars. 4 to 6, added by Resolucao BCB n. 402/2024; the duty to offer single and repeating schedules to natural persons is art. 10 as worded by Resolucao BCB n. 425/2024. The send window, the retry and the limit case are IN 513 art. 12 caput and pars. 1, 2 and 5; the month end rule art. 13; the cancellation cut-off art. 14. The channel and the two clocks are Manual de Tempos 1.1 and 1.2, and footnote 1 names the pacs.008 values. The summary's earlier mention of other message types on the secondary channel came from the Catalogo de Servicos do SFN, which this redraft did not reopen, so it is left out. Pix has no standard entry class code, so sec_code is null.", "confidence": "high" }, "currency": { "effective_since": "2020-11-03", "effective_to": null, "effective_note": "Redrafted 2026-09-23 from the documents named in basis, replacing the migration's 'Long-standing'. Pix Agendado is defined in art. 8 of the Regulamento as first approved by Resolucao BCB n. 1/2020, and Pix began operating on 2020-11-03 (restricted) and 2020-11-16 (full) under that Resolucao's art. 9; the earlier date is used, as on Pix Cobranca. [Inference] that the product was available from the first day of operation rather than from full operation. Later layers carry their own dates: the retry and key check came with Resolucao BCB n. 402/2024, the duty to offer came with Resolucao BCB n. 425/2024, and IN 513 arts. 12 to 14 have been in force since 2024-10-28 (art. 17 I), with the user experience requirements for Pix Agendado taking effect on 2025-04-01.", "source_edition": "Regulamento Pix annexed to Resolucao BCB n. 1/2020, consolidated text version 41 as served on 2026-09-23, Chapter V, Section II, Subsection I; Instrucao Normativa BCB n. 513 de 30/8/2024, consolidated text as served on 2026-09-23; Manual de Tempos do Pix version 7.0", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "pix:rule.agendado-a-repeat-date-the-month-lacks-moves-to-the-1st", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.agendado-and-scheduled-charges-settle-00-to-08-with-an-evening-retry", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.finality-how-fast-that-has-to-happen", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.messages-two-channels-and-the-first-message-picks-one", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.settlement-two-message-channels-two-clocks", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:txn.pix-automatico", "id": "txn.pix-automatico", "rail": "pix", "class": "TransactionType", "name": "Pix Automatico", "summary": "A recurring Pix for paying a business. The payer authorises it once, at their own bank, before the first charge; after that the business's bank sends a payment instruction for each charge, from 2 to 10 days before it is due, and the payer's bank schedules it and sends the payment itself on the due date between 00:00 and 08:00, retrying that evening if funds or limit fall short. Every collection is a credit push from the payer's bank, not a debit taken by the business, and it settles as an ordinary Pix. Only a legal person whose CNPJ has been active for at least six months can be offered it as the receiver; every participant holding accounts must offer it to its customers as payers, though one may ask the BCB to be excused for business accounts.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "arts. 11-Q to 11-V", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "section": "arts. 5 to 7 and 17 II", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Regulamento Pix arts. 11-Q to 11-V (consolidated version 41) and IN BCB n. 513/2024 arts. 2 to 9, 15-A and 17, both read in Portuguese on 2026-09-23 from the BCB normativos data endpoint. The definition (the payer's bank starts each Pix on receiving periodic instructions from the receiver's bank, under a prior specific authorisation) is art. 11-Q; the mandatory offer to payers and the optional offer to receivers are arts. 11-S and 11-T; the six month CNPJ condition is art. 11-T par. 1 as worded by Resolucao BCB n. 482/2025 from 2025-06-16. The 2 to 10 day window is IN 513 art. 5 par. 1, the 00:00 to 08:00 send and the 18:00 to 21:00 retry are art. 7 caput and par. 1. That the payment settles as an ordinary Pix is [Inference] from art. 11-Q, which defines the product as the payer's bank initiating a Pix. Pix has no standard entry class code, so sec_code is null.", "confidence": "high" }, "currency": { "effective_since": "2025-06-16", "effective_to": null, "effective_note": "Redrafted 2026-09-23 from the documents named in basis, replacing the 2026-09 Orca Core migration stub (effective 'Long-standing', no source opened). The Regulamento's Pix Automatico subsection was added by Resolucao BCB n. 402 of 22/7/2024; IN BCB n. 513/2024 art. 17 II puts its Pix Automatico procedures in force on 2025-06-16, the date used here, as on the Mandate. The stub's corroboration of 2026-09-22 checked the earlier summary; the summary is new, so the record returns to draft and awaits re-validation.", "source_edition": "Regulamento Pix annexed to Resolucao BCB n. 1/2020, consolidated text version 41 as served on 2026-09-23, Chapter V, Section II, Subsection IV; Instrucao Normativa BCB n. 513 de 30/8/2024, consolidated text as served on 2026-09-23, with the amendments by IN BCB n. 614/2025, n. 634/2025 and n. 743/2026 shown in place", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-catalogo-servicos-sfn-vol-vi-5-12", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "The periodic payment messages sections confirm the payer authorises a recurrence in advance through the pain.009 or pain.012 flow, the receiving participant sends the payment instruction as pain.013 on each due charge, and the payer's participant then starts the payment on the due date." }, { "source": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms the Pix Automatico definition at art 11-Q as the payer bank initiating a Pix on periodic instructions from the receiver bank under a prior specific authorisation, the mandatory offer to payers by every account provider at art 11-S, the optional offer to receivers at art 11-T, and the six month active CNPJ condition for the receiver at art 11-T par 1 as worded by Resolucao BCB 482/2025" }, { "source": "pix:src.bcb-in-513-2024-pix-automatico-agendado-cobranca", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms the 2 to 10 calendar day window for sending the collection instruction at art 5 par 1, the 00:00 to 08:00 settlement window at art 7 caput, and the 18:00 to 21:00 same day retry at art 7 par 1" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:mandate.pix-automatico-authorisation", "type": "authorises", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-a-cycle-on-a-day-the-month-lacks", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-a-faulty-payment-is-refunded-within-24-hours", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-a-pending-request-lapses-after-30-days", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-a-pre-approved-credit-line-may-fund-it", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-a-settlement-error-allows-a-same-day-resend", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-a-standing-authorisation-not-a-debit-pull", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-cancelling-one-scheduled-payment", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-cancelling-the-authorisation-stops-what-is-scheduled", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-either-side-may-cancel-the-authorisation", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-five-recurrence-periods", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-four-journeys-to-an-authorisation", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-instructions-go-2-to-10-days-ahead", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-journey-3-needs-the-first-payment-to-settle", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-retries-on-later-days", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-settlement-date-is-the-due-date", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-settles-between-00-and-08-with-an-evening-retry", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-the-pacs008-is-marked-auto", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-the-payer-sets-the-maximum-the-business-sets-its-floor", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-the-payers-bank-schedules-within-2-hours-or-refuses", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-three-refusal-families-and-who-raises-them", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-what-an-authorisation-must-state", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-what-the-payer-may-edit-and-when-it-bites", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.automatico-who-may-offer-and-who-may-collect", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.cobranca-static-dynamic-and-composite-qr-codes", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.liability-pix-automatico-the-payers-bank-pays-first", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.messages-pix-automatico-authorization-messages", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.messages-pix-automatico-instruction-messages", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:txn.pix-cobranca", "id": "txn.pix-cobranca", "rail": "pix", "class": "TransactionType", "name": "Pix Cobranca", "summary": "A Pix paid against a charge the receiving end user prepared through its bank, rather than one the payer keys in. A charge is either for immediate payment, as at a till or an online checkout, or for payment by a due date, where interest, a fine, a discount or a rebate may change what is owed. Once the payer starts paying it the payment runs as an ordinary Pix.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "section": "arts. 11-A, 11-B, 11-C, 11-D and 11-E", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "pix:src.bcb-manual-padroes-iniciacao-pix-2-10-0", "section": "sections 2.4, 2.7 and Annex I section 5.1", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Regulamento Pix arts. 11-A to 11-E and the Manual de Padroes para Iniciacao do Pix 2.10.0 sections 2.4 and 2.7, both read 2026-09-22. The Regulamento also lists payments for a withdrawal service as a third kind of charge; those belong to Pix Saque and Pix Troco and are left to those records. Pix has no entry class code, so sec_code is null.", "confidence": "high" }, "currency": { "effective_since": "2020-11-03", "effective_to": null, "effective_note": "Drafted 2026-09-22 by the Pix Automatico and Cobranca drafting session from the documents named in basis, each opened and read that day.", "source_edition": "Regulamento Pix annexed to Resolucao BCB n. 1/2020, consolidated text as served on 2026-09-22, Chapter V, Section II; Manual de Padroes para Iniciacao do Pix version 2.10.0 of 2026-08-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-24", "checked_by": "Claude validator (Sonnet)", "notes": "Confirms Pix Cobranca at art 11-A as a facility for the receiving user to manage and receive charges, split into immediate payments (inciso I) and due date payments allowing interest, fines, other additions, discounts and rebates (inciso II), and confirms at art 11-B that once a Pix Cobranca payment is started it follows the ordinary Pix flow of Chapters VIII, IX and X" } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:rule.agendado-and-scheduled-charges-settle-00-to-08-with-an-evening-retry", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.cobranca-a-charge-takes-one-payment-and-an-identifier-is-never-reused", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.cobranca-a-due-date-charge-rolls-to-the-payers-next-business-day", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.cobranca-a-static-code-leaves-reconciliation-to-the-receiver", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.cobranca-an-immediate-charge-lives-24-hours-by-default", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.cobranca-immediate-and-due-date-charges", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.cobranca-static-dynamic-and-composite-qr-codes", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.cobranca-the-payees-bank-computes-the-final-amount", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:txn.pix-saque", "id": "txn.pix-saque", "rail": "pix", "class": "TransactionType", "name": "Pix Saque", "summary": "A Pix that pays a withdrawal agent so the payer can take cash. The cash leg is outside the special return mechanism and has its own one hour return clock.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [], "basis": { "sources": "Written by the 2026-09 Orca Core migration from the pix rail facts whose detail lines name this product; Pix has no standard entry class code, so sec_code is null. No source was opened for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Regulamento Pix (Resolucao BCB n. 1/2020) consolidated version 41; Regulamento do SPI (Resolucao BCB n. 195/2022); Manual de Tempos do Pix 7.0; Manual Operacional do DICT 8.5; Catalogo de Servicos do SFN Vol. VI 5.12", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 41-B par. 2 confirms the MED does not apply to Pix Saque, and art. 41 par. 2 confirms the withdrawal leg carries its own one hour return clock once the withdrawal facilitator or agent verifies a return is due." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:rule.limits-withdrawal-and-change-carry-hard-ceilings", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.return-pix-saque-and-pix-troco-a-different-starter-and", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:txn.pix-troco", "id": "txn.pix-troco", "rail": "pix", "class": "TransactionType", "name": "Pix Troco", "summary": "A Pix that pays for a purchase and a cash change amount in one order, so the two parts carry different return reasons and different clocks.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [], "basis": { "sources": "Written by the 2026-09 Orca Core migration from the pix rail facts whose detail lines name this product; Pix has no standard entry class code, so sec_code is null. No source was opened for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Regulamento Pix (Resolucao BCB n. 1/2020) consolidated version 41; Regulamento do SPI (Resolucao BCB n. 195/2022); Manual de Tempos do Pix 7.0; Manual Operacional do DICT 8.5; Catalogo de Servicos do SFN Vol. VI 5.12", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 41 par. 3 and par. 4 confirm the cash part of a Pix Troco is returned by its own transaction, separate from the purchase part, and art. 41-A caput inciso II confirms only the cash part sits outside the 90 day return window." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:rule.limits-withdrawal-and-change-carry-hard-ceilings", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.return-pix-saque-and-pix-troco-a-different-starter-and", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.return-pix-troco-needs-two-returns", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "pix:txn.pix", "id": "txn.pix", "rail": "pix", "class": "TransactionType", "name": "Pix (ordinary credit transfer)", "summary": "A credit push in Brazilian reais between transactional accounts held at Pix participants, settled in seconds and irrevocable once settled.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [], "basis": { "sources": "Written by the 2026-09 Orca Core migration from the pix rail facts whose detail lines name this product; Pix has no standard entry class code, so sec_code is null. No source was opened for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Regulamento Pix (Resolucao BCB n. 1/2020) consolidated version 41; Regulamento do SPI (Resolucao BCB n. 195/2022); Manual de Tempos do Pix 7.0; Manual Operacional do DICT 8.5; Catalogo de Servicos do SFN Vol. VI 5.12", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "checked_on": "2026-09-22", "checked_by": "validator-sonnet-2026-09-22", "notes": "Art. 2 inciso II confirms an instant payment is a real time, 24 hour fund transfer, art. 2 inciso III confirms it is a credit order, and art. 40 confirms settlement is irrevocable and unconditional once effected; the Regulamento Pix confirms it runs in Brazilian reais between transactional accounts at Pix participants." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "pix:rule.finality-how-fast-that-has-to-happen", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.messages-the-payment-pair", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "pix:rule.settlement-credit-push-only-national-currency-immediate", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "pix:rule.consumer-law-the-rulebook-obliges-a-good-experience-in-terms", "pix:rule.consumer-law-the-night-ceiling-is-the-single-most-concrete", "pix:rule.limits-cuts-are-immediate-increases-are-slow-on-purpose", "pix:rule.consumer-law-the-limit-panel-must-be-where-the-customer", "pix:rule.consumer-law-a-freeze-the-customer-never-has-to-ask-for", "pix:rule.consumer-law-a-complaint-can-start-a-recovery", "pix:rule.consumer-law-a-fee-rule-and-a-disclosure-rule", "pix:rule.liability-where-disagreements-go", "pix:rule.consumer-law-the-general-customer-protection-resolution-has-a", "pix:rule.liability-what-the-bcb-says-the-rulebook-is" ], "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.", "relations": [ { "type": "see_also", "to": "pix:limits", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:hours", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:decision-points", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "boleto:consumer-law", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:consumer-law", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:decision-points", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:finality", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:hours", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:liability", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:limits", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:refund", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "pix:rule.decision-points-is-the-suspicion-well-founded", "pix:rule.decision-points-whether-to-hold-a-payment-before-it-settles", "pix:rule.decision-points-whether-to-freeze-money-as-it-lands", "pix:rule.decision-points-what-to-do-at-the-end-of-72-hours", "pix:rule.decision-points-whether-to-open-a-recovery-on-the-customers-word", "pix:rule.decision-points-whether-to-accept-an-infraction-notice-about", "pix:rule.decision-points-whether-to-cancel-a-recovery-you-opened", "pix:rule.decision-points-whether-to-honour-a-return-request-at-all", "pix:rule.refund-the-operational-failure-route-is-narrower-than", "pix:rule.decision-points-whether-to-raise-a-customers-limit", "pix:rule.decision-points-whether-to-lift-a-block-on-a-flagged-account", "pix:rule.decision-points-where-the-dict-decides-instead-of-a-person" ], "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.", "relations": [ { "type": "see_also", "to": "pix:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:limits", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:consumer-law", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "mx-spei:decision-points", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:consumer-law", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:finality", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:liability", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:limits", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:recall", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:refund", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "pix:rule.finality-the-moment-of-finality", "pix:rule.finality-how-fast-that-has-to-happen", "pix:rule.finality-the-system-presumes-the-order-is-good", "pix:rule.finality-there-is-no-sender-cancellation-and-no", "pix:rule.finality-one-cancellation-window-does-exist-before", "pix:rule.finality-second-layer-a-return-is-a-new-payment-not-a", "pix:rule.finality-third-layer-the-money-can-be-frozen-the-instant", "pix:rule.finality-fourth-layer-finality-does-not-settle-who-bears", "pix:rule.settlement-settlement-outside-the-spi" ], "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.", "relations": [ { "type": "see_also", "to": "pix:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:hours", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:consumer-law", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:decision-points", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "boleto:rule.boleto-paid-through-other-arrangement", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "boleto:finality", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:finality", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:decision-points", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:hours", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:liability", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:recall", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:refund", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:return", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:settlement", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "pix:rule.hours-the-spi-never-closes", "pix:rule.hours-an-instant-payment-is-defined-as-always", "pix:rule.hours-banks-must-be-open-too", "pix:rule.hours-the-dict-never-closes-either", "pix:rule.hours-what-a-bank-must-offer-its-own-customers-is", "pix:rule.hours-payment-clocks-40-seconds-or-45-minutes", "pix:rule.hours-the-fraud-hold-runs-on-business-hours", "pix:rule.hours-the-night-period-is-a-value-rule-not-a-closing", "pix:rule.hours-messages-are-in-utc-rules-speak-brasilia", "pix:rule.hours-availability-is-measured-and-has-a-floor" ], "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.", "relations": [ { "type": "see_also", "to": "pix:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:limits", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:consumer-law", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "boleto:hours", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:hours", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:consumer-law", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:finality", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:limits", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:messages", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:participants", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:settlement", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "pix:rule.liability-the-requesting-participant-owns-the-med-return", "pix:rule.liability-a-bad-rejection-makes-the-receiving-bank", "pix:rule.liability-pix-automatico-the-payers-bank-pays-first", "pix:rule.liability-the-duty-to-reject-on-both-sides", "pix:rule.liability-the-duty-to-freeze-on-arrival", "pix:rule.liability-the-hold-is-no-longer-limited-to-individuals", "pix:rule.liability-fraud-risk-management-is-a-stated-obligation", "pix:rule.liability-an-accepted-notice-shuts-the-account-out-of-pix", "pix:rule.liability-access-devices-must-be-registered", "pix:rule.liability-where-disagreements-go", "pix:rule.liability-non-compliance-is-a-supervision-matter", "pix:rule.liability-what-the-bcb-says-the-rulebook-is" ], "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.", "relations": [ { "type": "see_also", "to": "pix:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:consumer-law", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:participants", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:decision-points", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "mx-spei:liability", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:consumer-law", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:decision-points", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:finality", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:participants", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:recall", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:refund", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:return", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "pix:rule.limits-the-network-sets-no-ceiling", "pix:rule.limits-why-a-bank-may-set-a-limit-at-all", "pix:rule.limits-the-night-limit-for-person-to-person", "pix:rule.limits-the-day-limit-is-no-longer-pegged-to-ted", "pix:rule.limits-the-user-can-drive-the-limit-in-both-directions", "pix:rule.limits-cuts-are-immediate-increases-are-slow-on-purpose", "pix:rule.limits-withdrawal-and-change-carry-hard-ceilings", "pix:rule.limits-contactless-and-initiation-without-redirection", "pix:rule.limits-a-ceiling-aimed-at-the-weakest-technical-link", "pix:rule.limits-no-limit-on-how-many", "pix:rule.limits-limits-an-operator-will-not-see-in-a-return" ], "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.", "relations": [ { "type": "see_also", "to": "pix:hours", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:consumer-law", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:participants", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:decision-points", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "pix:src.bcb-in-512-2024-limites", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "mx-spei:limits", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:consumer-law", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:decision-points", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:hours", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:participants", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:return", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:settlement", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "pix:rule.messages-the-standard-and-the-envelope", "pix:rule.messages-the-payment-pair", "pix:rule.messages-the-return-pair-and-its-four-reasons", "pix:rule.messages-rejection-reasons-live-on-the-pacs-002", "pix:rule.messages-two-channels-and-the-first-message-picks-one", "pix:rule.messages-pix-automatico-authorization-messages", "pix:rule.messages-pix-automatico-instruction-messages", "pix:rule.messages-reporting-payments-that-never-touched-the-spi", "pix:rule.messages-disputes-are-rest-not-iso", "pix:rule.messages-resending-is-safe-by-design", "pix:rule.messages-two-catalogs-alive-at-once" ], "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.", "relations": [ { "type": "see_also", "to": "pix:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:hours", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:participants", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "pix:src.bcb-catalogo-servicos-sfn-vol-vi-5-12", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "boleto:rule.boleto-paid-through-other-arrangement", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.pix-qr-on-boleto", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "boleto:messages", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:messages", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:hours", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:participants", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:recall", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:return", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:settlement", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "pix:rule.participants-who-has-to-join", "pix:rule.participants-five-roles-and-they-are-not-interchangeable", "pix:rule.participants-direct-or-indirect-is-a-separate-question", "pix:rule.participants-what-a-direct-spi-participant-signs-up-to", "pix:rule.participants-somebody-has-to-vouch-for-a-smaller-institution", "pix:rule.participants-who-is-allowed-to-be-a-responsible-participant", "pix:rule.participants-payment-institutions-can-join-before-they-are", "pix:rule.participants-leaving-takes-90-days-and-does-not-end", "pix:rule.participants-a-responsible-participant-that-walks-away-owes", "pix:rule.participants-how-participants-are-identified-and-where-to" ], "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.", "relations": [ { "type": "see_also", "to": "pix:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:limits", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:hours", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "boleto:participants", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:participants", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:liability", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:limits", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:messages", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:settlement", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "pix:rule.recall-no-cancellation-no-recall-message", "pix:rule.recall-what-the-special-mechanism-is-for", "pix:rule.recall-two-grounds-it-never-covers", "pix:rule.recall-who-actually-sends-the-money-back", "pix:rule.recall-the-request-goes-over-dict-not-over-iso", "pix:rule.recall-for-fraud-the-dict-drives-the-whole-thing", "pix:rule.recall-the-window-to-ask-is-80-days", "pix:rule.recall-asking-freezes-money-immediately", "pix:rule.recall-the-recovering-bank-must-police-its-own-request", "pix:rule.recall-fraud-marking-is-a-separate-thing-from-asking" ], "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.", "relations": [ { "type": "see_also", "to": "pix:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:decision-points", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "mx-spei:recall", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:decision-points", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:finality", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:liability", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:messages", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:refund", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:return", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "pix:rule.liability-pix-automatico-the-payers-bank-pays-first", "pix:rule.refund-everything-else-presupposes-funds", "pix:rule.refund-the-72-hour-clock-on-the-return-stage", "pix:rule.refund-how-much-each-bank-has-to-pay-back", "pix:rule.refund-four-different-ways-the-money-travels", "pix:rule.refund-grounds-a-receiving-bank-may-give-for-paying", "pix:rule.refund-rejecting-the-refund-does-not-undo-the-fraud", "pix:rule.refund-accepting-even-with-no-money-is-expected", "pix:rule.refund-the-operational-failure-route-is-narrower-than", "pix:rule.refund-money-must-be-unblocked-at-only-three-moments" ], "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.", "relations": [ { "type": "see_also", "to": "pix:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:consumer-law", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:decision-points", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "pix:src.bcb-manual-operacional-dict-8-5", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:refund", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.boleto-paid-through-other-arrangement", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "boleto:refund", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:refund", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:consumer-law", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:decision-points", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:finality", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:liability", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:recall", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:return", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:refund", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "pix:rule.return-who-may-start-one", "pix:rule.return-what-the-receiving-users-bank-then-does", "pix:rule.return-the-90-day-window", "pix:rule.return-funds-must-actually-be-there", "pix:rule.return-partial-and-repeated-returns", "pix:rule.return-the-reason-code-an-operator-will-see", "pix:rule.return-a-return-travels-on-the-fast-channel-and-is", "pix:rule.return-pix-saque-and-pix-troco-a-different-starter-and", "pix:rule.return-pix-troco-needs-two-returns", "pix:rule.return-returns-do-not-consume-the-payers-limits" ], "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.", "relations": [ { "type": "see_also", "to": "pix:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:limits", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "pix:src.bcb-resolucao-1-2020-regulamento-pix", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "boleto:exc.interbank-devolucao", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "boleto:rule.boleto-paid-through-other-arrangement", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "boleto:return", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:return", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:consumer-law", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:decision-points", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:finality", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:liability", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:messages", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:recall", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:refund", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "pix:rule.settlement-what-the-spi-is", "pix:rule.settlement-credit-push-only-national-currency-immediate", "pix:rule.settlement-step-one-the-spi-blocks-the-sending-banks-funds", "pix:rule.settlement-balance-checks-need-not-follow-arrival-order", "pix:rule.settlement-step-two-the-receiving-bank-confirms-it-can-take", "pix:rule.settlement-step-three-the-balance-swap-is-settlement", "pix:rule.settlement-the-banks-own-authorization-step-comes-first", "pix:rule.settlement-two-message-channels-two-clocks", "pix:rule.settlement-settlement-outside-the-spi", "pix:rule.settlement-liquidity-for-the-conta-pi", "pix:rule.settlement-service-levels-not-just-deadlines" ], "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.", "relations": [ { "type": "see_also", "to": "pix:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:hours", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:limits", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "pix:participants", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "pix:src.bcb-resolucao-195-2022-regulamento-spi", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "boleto:rule.boleto-paid-through-other-arrangement", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "boleto:settlement", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "mx-spei:settlement", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:finality", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:hours", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:limits", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:messages", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "pix:participants", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:rail.rtp-reject", "id": "rail.rtp-reject", "class": "Rail", "rail": "rtp-reject", "name": "RTP Payment Rejects", "governing_authority": "The Clearing House", "country": "US", "currency": "USD", "operators": [ "The Clearing House Payments Company L.L.C." ], "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)" ], "relations": [ { "type": "sourced_from", "to": "rtp-reject:src.tch-rtp-operating-rules-2026-06-01", "section": "Rules IV.A, V.C and V.E.3", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "source_class": null, "effective_status_reason": null, "used_by": [] }, { "uid": "rtp-reject:exc.reject", "id": "exc.reject", "rail": "rtp-reject", "class": "Exception", "name": "Reject", "summary": "A payment message that the receiving participant or the RTP System turns down before settlement, with a reason code. The receiving participant rejects in its payment message response; the RTP System rejects on receipt when the message breaks the rules or specifications or the sending side's prefunded position falls short. The status reported back is RJCT in a pacs.002, or an admi.002 for some technical rejections, per the Cross River Bank pages.", "money_moves": false, "outcome": "The payment is not settled. The RTP System tells the sending participant, releases the amount it had reserved against the sending side's prefunded position, and the receiving side's position does not change. Nothing has to be returned; the sender may send a corrected new payment.", "relations": [ { "type": "initiated_by", "to": "rtp-reject:role.receiving-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "initiated_by", "to": "rtp-reject:role.rtp-system", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "rtp-reject:role.receiving-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "rtp-reject:role.rtp-system", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "rtp-reject:src.tch-rtp-operating-rules-2026-06-01", "section": "Rules IV.A.2, V.E.3, VI.E.2, VI.E.3, VI.E.5", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RTP Operating Rules effective 2026-06-01, Rules IV.A.2, V.E.3, VI.E.2, VI.E.3 and VI.E.5, read 2026-09-19. The pacs.002 and admi.002 message names are from the Cross River Bank error codes page, read 2026-09-19; no TCH document read names them for a reject.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted for OC-7 on 2026-09-19 from the RTP Operating Rules edition effective 2026-06-01; no rule change identified since.", "source_edition": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:exc.time-out-cancellation", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:rule.reject-response-timeout", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:rule.system-reject-on-receipt", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:1100", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:9912", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:9914", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:9934", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:9946", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:9947", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:9948", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:9952", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:9953", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:9956", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:9957", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:9964", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:AC02", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:AC03", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:AC04", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:AC06", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:AC07", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:AC11", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:AC13", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:AC14", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:AG01", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:AG03", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:AGNT", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:AM02", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:AM04", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:AM09", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:AM11", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:AM12", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:AM13", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:AM14", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:BE04", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:BE06", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:BE07", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:BE10", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:BE11", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:BE14", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:BE16", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:BE17", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:DS0H", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:DT04", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:DUPL", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:FF08", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:MD07", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:NARR", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:NOAT", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:RC01", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:RC02", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:RC03", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:RC04", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:TK01", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:TK02", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:TK03", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:TK04", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:TK05", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:TK06", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:TK07", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:TK08", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:TM01", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "rtp-reject:exc.time-out-cancellation", "id": "exc.time-out-cancellation", "rail": "rtp-reject", "class": "Exception", "name": "Time-out cancellation", "summary": "A payment message the receiving participant did not answer within the response time set in the RTP Technical Specifications. TCH cancels it and tells both participants. It is not a reject by the receiving participant, but the public bank and processor pages list its code (DS24) among the reject codes a sender sees.", "money_moves": false, "outcome": "The payment is not settled and the amount reserved against the sending side's prefunded position is released. It may go again only as a new payment message that meets the requirements for new messages.", "relations": [ { "type": "initiated_by", "to": "rtp-reject:role.rtp-system", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "rtp-reject:role.rtp-system", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "rtp-reject:src.tch-rtp-operating-rules-2026-06-01", "section": "Rules III.E, IV.A.4, VI.E.2, VI.E.5", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:exc.reject", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RTP Operating Rules effective 2026-06-01, Rules III.E, IV.A.4, VI.E.2 and VI.E.5, read 2026-09-19. That DS24 is the code this cancellation carries is [Inference] from the Trice and CU*Answers pages, which tie DS24 to a TCH time-out.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted for OC-7 on 2026-09-19 from the RTP Operating Rules edition effective 2026-06-01; no rule change identified since.", "source_edition": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:rule.reject-response-timeout", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:DS24", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "rtp-reject:role.receiving-participant", "id": "role.receiving-participant", "rail": "rtp-reject", "class": "Role", "name": "Receiving Participant", "summary": "The RTP participant that holds the receiver's account and gets the payment message. It must accept, accept without posting, or reject each payment message in time, and it sends the reject for the reasons that turn on the receiver's account or on law.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "rtp-reject:src.tch-rtp-operating-rules-2026-06-01", "section": "Rule I.A.73 (definition); Rule V (obligations)", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RTP Operating Rules effective 2026-06-01, Rule I.A.73 and Rule V, read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted for OC-7 on 2026-09-19 from the RTP Operating Rules edition effective 2026-06-01; no rule change identified since.", "source_edition": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:exc.reject", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:exc.reject", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:rule.reason-code-required", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:rule.receiver-reject-grounds", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:rule.reject-response-timeout", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:1100", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC02", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC03", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC04", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC06", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC07", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:AC11", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC13", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC14", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AG01", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AG03", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AGNT", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM02", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM04", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM09", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM11", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM12", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM14", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE04", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE06", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE07", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE10", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE11", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE14", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE16", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE17", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:DS0H", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:DT04", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:DUPL", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:FF08", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:MD07", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:NARR", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:NOAT", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC01", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC02", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC03", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC04", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK01", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK02", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK03", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK04", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK05", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK06", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK07", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK08", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TM01", "type": "returned_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:role.rtp-system", "id": "role.rtp-system", "rail": "rtp-reject", "class": "Role", "name": "RTP System", "summary": "The network TCH operates. It routes payment messages, may reject one on receipt that breaks the rules or the technical specifications or looks erroneous, must reject one the sending side's prefunded position does not cover, and cancels a payment the receiving participant leaves unanswered past the time-out.", "kind": "operator", "relations": [ { "type": "sourced_from", "to": "rtp-reject:src.tch-rtp-operating-rules-2026-06-01", "section": "Rule I.A.94 (definition); Rules IV.A.2, IV.A.3, IV.A.4, VI.E.1, VI.E.3", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RTP Operating Rules effective 2026-06-01, Rules I.A.94, IV.A and VI.E, read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted for OC-7 on 2026-09-19 from the RTP Operating Rules edition effective 2026-06-01; no rule change identified since.", "source_edition": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:exc.reject", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:exc.reject", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:exc.time-out-cancellation", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:exc.time-out-cancellation", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:rule.reject-before-settlement", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:rule.system-reject-grounds", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:rule.system-reject-on-receipt", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:1100", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:9912", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:9914", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:9934", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:9946", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:9947", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:9948", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:9952", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:9953", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:9956", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:9957", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:9964", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:AC02", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC13", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC14", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AG03", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AGNT", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM02", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM04", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM09", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM11", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM12", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM13", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM14", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE04", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE07", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE10", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE11", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE14", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE16", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:DS0H", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:DS24", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:DT04", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:DUPL", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:FF08", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:NARR", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:NOAT", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC01", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC02", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC03", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC04", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK01", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK02", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK03", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK04", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK05", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK06", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK07", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK08", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TM01", "type": "returned_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:role.sending-participant", "id": "role.sending-participant", "rail": "rtp-reject", "class": "Role", "name": "Sending Participant", "summary": "The RTP participant that holds the sender's account and sends the payment message. It is told when its payment is rejected, cannot cancel or amend a payment message once sent, and may set a lower per payment limit for its own senders.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "rtp-reject:src.tch-rtp-operating-rules-2026-06-01", "section": "Rule I.A.100 (definition); Rules II.C.2.a, III.E", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RTP Operating Rules effective 2026-06-01, Rules I.A.100, II.C.2.a and III.E, read 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted for OC-7 on 2026-09-19 from the RTP Operating Rules edition effective 2026-06-01; no rule change identified since.", "source_edition": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:rule.reject-before-settlement", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:rule.reason-code-required", "id": "rule.reason-code-required", "rail": "rtp-reject", "class": "Rule", "name": "A reject carries a reason code", "statement": "A receiving participant that rejects must give a reason code, and it must be a code the RTP Technical Specifications allow for the reject and the one that fits the case best. The permitted list is in those specifications, not in the Operating Rules.", "rests_on": "rule", "relations": [ { "type": "sourced_from", "to": "rtp-reject:src.tch-rtp-operating-rules-2026-06-01", "section": "Rule V.E.3.b; Rule I.D (technical specifications and ISO 20022 terms)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "rtp-reject:role.receiving-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "rtp-reject:txn.credit-transfer", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RTP Operating Rules effective 2026-06-01, Rules V.E.3.b and I.D, read 2026-09-19. The list of permitted codes itself was not consulted: it sits in the RTP Technical Specifications, whose terms Orca has not accepted.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted for OC-7 on 2026-09-19 from the RTP Operating Rules edition effective 2026-06-01; no rule change identified since.", "source_edition": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "rtp-reject:src.tch-rtp-operating-rules-2026-06-01", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Rule V.E.3.b that a receiving participant's reject message must include a valid and most appropriate reason code as specified in the RTP Technical Specifications, and Rule I.D that those specifications carry ISO 20022 based terminology." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:exc.reject", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:1100", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC06", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC07", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC11", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC13", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC14", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AG01", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AG03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AGNT", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM09", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM11", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM12", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM14", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE06", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE07", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE10", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE11", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE14", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE16", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE17", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:DS0H", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:DT04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:DUPL", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:FF08", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:MD07", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:NARR", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:NOAT", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC01", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK01", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK05", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK06", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK07", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK08", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TM01", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:rule.receiver-reject-grounds", "id": "rule.receiver-reject-grounds", "rail": "rtp-reject", "class": "Rule", "name": "When a receiving participant may reject", "statement": "A receiving participant has to accept every payment message that meets the RTP Technical Specifications, with three exceptions: law or regulatory compliance stands in the way; the account holder has told it not to take some or all RTP payments; or the receiver's account is not a Regulation D transaction account, is closed or invalid, or is being watched because fraud or other illegal activity is suspected. It may not set its own lower per payment limit for receivers, and may not set cut-off times that push a payment into another RTP day. A new payment to a closed account should be rejected rather than accepted without posting. When it rejects on these grounds it owes the receiver no status information.", "rests_on": "rule", "relations": [ { "type": "sourced_from", "to": "rtp-reject:src.tch-rtp-operating-rules-2026-06-01", "section": "Rules V.C, II.C.2.b, V.B, V.E.2.a.ii, II.F.1.a", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "rtp-reject:role.receiving-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "rtp-reject:txn.credit-transfer", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RTP Operating Rules effective 2026-06-01, Rules V.C, V.B, V.E.2.a.ii, II.C.2.b and II.F.1.a, read 2026-09-19. Stated in Orca's words and order. Which reason code fits which ground is not in the Operating Rules; the code records give Orca's reading, marked as inference.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted for OC-7 on 2026-09-19 from the RTP Operating Rules edition effective 2026-06-01; no rule change identified since.", "source_edition": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "rtp-reject:src.tch-rtp-operating-rules-2026-06-01", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Rule V.C's three grounds on which a receiving participant need not accept a payment message, Rule II.C.2.b that a receiving participant may not set a lower transaction limit for its receivers, Rule V.B on cut off times that would push a payment to a different RTP day, Rule V.E.2.a.ii that a new payment to a closed account should get a reject rather than an accept without posting response, and Rule II.F.1.a that a reject on these grounds carries no duty to give the receiver status information." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:exc.reject", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:1100", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC06", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC07", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC11", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC13", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC14", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AG01", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AG03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AGNT", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM09", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM11", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM12", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM14", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE06", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE07", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE10", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE11", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE14", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE16", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE17", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:DS0H", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:DT04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:DUPL", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:FF08", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:MD07", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:NARR", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:NOAT", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC01", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK01", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK05", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK06", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK07", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK08", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TM01", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:rule.reject-before-settlement", "id": "rule.reject-before-settlement", "rail": "rtp-reject", "class": "Rule", "name": "A rejected or cancelled payment is never settled", "statement": "Rejection comes before settlement, never after it. On release the RTP System holds the amount against the sending side's prefunded position; if the payment is then rejected or cancelled for time-out, the hold is lifted and the receiving side's position is untouched, so no money moved and none has to come back. The sending participant owes the amount only from the moment the receiving participant accepts, or accepts without posting; that response and settlement are simultaneous and final, so from then on a reject is no longer possible.", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "rtp-reject:src.tch-rtp-operating-rules-2026-06-01", "section": "Rules V.E.3.c, III.D, VI.E.2, VI.E.4, VI.E.5, VI.E.6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "rtp-reject:role.rtp-system", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "rtp-reject:role.sending-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "rtp-reject:txn.credit-transfer", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RTP Operating Rules effective 2026-06-01, Rules V.E.3.c, III.D, VI.E.2 and VI.E.4 to VI.E.6, read 2026-09-19. Stated in Orca's words.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted for OC-7 on 2026-09-19 from the RTP Operating Rules edition effective 2026-06-01; no rule change identified since.", "source_edition": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "rtp-reject:src.tch-rtp-operating-rules-2026-06-01", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Rule V.E.3.c that a rejected payment is never settled, Rule III.D that the sending participant's obligation to pay arises only on an accept or accept without posting message and is satisfied on settlement under Rule VI.E, and Rules VI.E.2, VI.E.4, VI.E.5 and VI.E.6 on how the System reserves and then releases or un-reserves the amount around a cancellation, rejection or settlement." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:exc.reject", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:exc.time-out-cancellation", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:1100", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:9912", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:9914", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:9934", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:9946", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:9947", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:9948", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:9952", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:9953", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:9956", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:9957", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:9964", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC06", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC07", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC11", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC13", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC14", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AG01", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AG03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AGNT", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM09", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM11", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM12", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM13", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM14", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE06", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE07", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE10", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE11", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE14", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE16", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE17", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:DS0H", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:DS24", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:DT04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:DUPL", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:FF08", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:MD07", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:NARR", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:NOAT", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC01", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK01", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK05", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK06", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK07", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK08", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TM01", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:rule.reject-response-timeout", "id": "rule.reject-response-timeout", "rail": "rtp-reject", "class": "Rule", "name": "Receiving participant response time-out", "statement": "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.", "rests_on": "rule", "relations": [ { "type": "sourced_from", "to": "rtp-reject:src.tch-rtp-operating-rules-2026-06-01", "section": "Rules V.A, IV.A.4, III.E", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "rtp-reject:exc.reject", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "rtp-reject:exc.time-out-cancellation", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "rtp-reject:role.receiving-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "rtp-reject:txn.credit-transfer", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RTP Operating Rules effective 2026-06-01, Rules V.A, IV.A.4 and III.E, read 2026-09-19. The time-out figure is set in the RTP Technical Specifications, which were not consulted; no public source read states it.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted for OC-7 on 2026-09-19 from the RTP Operating Rules edition effective 2026-06-01; no rule change identified since.", "source_edition": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "rtp-reject:src.tch-rtp-operating-rules-2026-06-01", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Rule V.A that a receiving participant must respond within the timeframe the RTP Technical Specifications set, Rule IV.A.4 that TCH cancels an unanswered payment message and notifies both participants, and Rule III.E that only TCH can cancel a sent payment message, only for a time out." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:exc.time-out-cancellation", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:1100", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC06", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC07", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC11", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC13", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC14", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AG01", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AG03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AGNT", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM09", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM11", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM12", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM14", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE06", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE07", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE10", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE11", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE14", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE16", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE17", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:DS0H", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:DS24", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:DT04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:DUPL", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:FF08", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:MD07", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:NARR", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:NOAT", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC01", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK01", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK05", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK06", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK07", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK08", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TM01", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:rule.system-reject-grounds", "id": "rule.system-reject-grounds", "rail": "rtp-reject", "class": "Rule", "name": "When the RTP System rejects", "statement": "The RTP System must reject a payment message that the sending side cannot cover: the sending participant's prefunded position, or its funding provider's, is below the amount, or the payment would take a non-funding group member past its net send limit. TCH may also reject a message that breaks the Operating Rules or the technical specifications, and may refuse to process one it believes erroneous, an apparent duplicate for example.", "rests_on": "rule", "relations": [ { "type": "sourced_from", "to": "rtp-reject:src.tch-rtp-operating-rules-2026-06-01", "section": "Rules VI.E.1, VI.E.3, IV.A.2, IV.A.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "rtp-reject:role.rtp-system", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "rtp-reject:txn.credit-transfer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RTP Operating Rules effective 2026-06-01, Rules IV.A.2, IV.A.3, VI.E.1 and VI.E.3, read 2026-09-19. Stated in Orca's words and order.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted for OC-7 on 2026-09-19 from the RTP Operating Rules edition effective 2026-06-01; no rule change identified since.", "source_edition": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "rtp-reject:src.tch-rtp-operating-rules-2026-06-01", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Rules VI.E.1 and VI.E.3 that the System will not release, and must reject, a payment message when the sending side's prefunded position is insufficient or a non-funding group member would exceed its net send limit, and Rules IV.A.2 and IV.A.3 that TCH may reject a message that breaks the rules or specifications and may decline to process one it believes erroneous, including an apparent duplicate." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:exc.reject", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:1100", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:9912", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:9914", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:9934", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:9946", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:9947", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:9948", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:9952", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:9953", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:9956", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:9957", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:9964", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC13", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC14", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AG03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AGNT", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM09", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM11", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM12", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM13", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM14", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE07", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE10", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE11", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE14", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE16", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:DS0H", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:DT04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:DUPL", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:FF08", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:NARR", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:NOAT", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC01", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK01", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK05", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK06", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK07", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK08", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TM01", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:rule.system-reject-on-receipt", "id": "rule.system-reject-on-receipt", "rail": "rtp-reject", "class": "Rule", "name": "RTP System reject: on receipt", "statement": "On receipt, before the RTP System releases the payment message to the receiving participant.", "rests_on": "rule", "relations": [ { "type": "sourced_from", "to": "rtp-reject:src.tch-rtp-operating-rules-2026-06-01", "section": "Rules IV.A.1, IV.A.2, VI.E.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "rtp-reject:exc.reject", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "rtp-reject:role.rtp-system", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "rtp-reject:txn.credit-transfer", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RTP Operating Rules effective 2026-06-01, Rules IV.A.1, IV.A.2 and VI.E.1, read 2026-09-19: the System routes a message only after its checks and releases it only when the sending side's position covers it. [Inference] that every RTP System reject happens before release; the rules do not say so in terms.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted for OC-7 on 2026-09-19 from the RTP Operating Rules edition effective 2026-06-01; no rule change identified since.", "source_edition": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "rtp-reject:src.tch-rtp-operating-rules-2026-06-01", "checked_on": "2026-09-19", "checked_by": "validator-sonnet-2026-09-19", "notes": "Confirms Rule IV.A.1 that the System accepts eligible payment messages and routes them to the receiving participant, Rule IV.A.2 that TCH may review and reject a payment message on receipt, and Rule VI.E.1 that release to the receiving participant depends on the sending side's prefunded position being sufficient; the record's inference that a System reject on these grounds happens before release is not itself stated in these rules." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:rule.system-reject-grounds", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:1100", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:9912", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:9914", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:9934", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:9946", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:9947", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:9948", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:9952", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:9953", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:9956", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:9957", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:9964", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC13", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC14", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AG03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AGNT", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM09", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM11", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM12", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM13", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM14", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE07", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE10", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE11", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE14", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE16", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:DS0H", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:DT04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:DUPL", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:FF08", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:NARR", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:NOAT", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC01", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK01", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK04", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK05", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK06", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK07", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK08", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TM01", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:src.crossriver-instant-error-codes", "id": "src.crossriver-instant-error-codes", "rail": "rtp-reject", "class": "RuleSource", "name": "Error codes: Instant payments (Cross River Bank)", "summary": "A bank's public developer page of error codes for instant payments. Only its section on the RTP codes TCH defines outside ISO 20022 is used; that section says those codes come back in pacs.002 or, for technical rejections, admi.002. Its mixed FedNow and RTP table and its generic ISO list are not used.", "publisher": "Cross River Bank", "url": "https://docs.crossriver.com/apis/payments/instant-payments/error-codes-instant-payments", "source_class": "secondary", "kind": "bank_developer_documentation", "edition": "live page; page data updatedAt 2026-09-17 [Inference]", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The page itself, fetched and read 2026-09-19. Same host and publisher as the Cross River request and response codes page, so the two are one source family.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created for OC-7 on 2026-09-19. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "live page; page data updatedAt 2026-09-17 [Inference]", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "rtp-reject:src.crossriver-instant-request-response-codes", "id": "src.crossriver-instant-request-response-codes", "rail": "rtp-reject", "class": "RuleSource", "name": "Request and response codes: Instant payments (Cross River Bank)", "summary": "A bank's public developer page for its instant payments service. Its reject and reason code list (the resultCode values) covers RTP payments routed through TCH; it also carries Cross River's own codes (650, 690, BLKD, INSF), which Orca does not treat as network codes.", "publisher": "Cross River Bank", "url": "https://docs.crossriver.com/apis/payments/instant-payments/request-and-response-codes-instant-payments", "source_class": "secondary", "kind": "bank_developer_documentation", "edition": "live page; its page data carries updatedAt values of 2026-05-17 and 2026-09-03, and which is the page's own is not stated [Inference]", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The page itself, fetched and read 2026-09-19. With its sister page on error codes it is one source family (family A in the rtp brief); it never counts as a second source for a code the sister page supports.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created for OC-7 on 2026-09-19. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "live page; its page data carries updatedAt values of 2026-05-17 and 2026-09-03, and which is the page's own is not stated [Inference]", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "rtp-reject:src.cuanswers-rtp-return-codes", "id": "src.cuanswers-rtp-return-codes", "rail": "rtp-reject", "class": "RuleSource", "name": "RTP Return Codes (CU*Answers)", "summary": "A credit union service organisation's public PDF. Its Appendix B lists the reject codes a credit union may see on RTP; its Appendix A lists request for return reasons, which are not used here.", "publisher": "CU*Answers", "url": "https://www.cuanswers.com/wp-content/uploads/Return-Codes.pdf", "source_class": "secondary", "kind": "pdf_document", "edition": "PDF titled RTP Return Codes, created 2023-06-09, modified 2024-08-30", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The PDF itself, fetched and read 2026-09-19 (family C in the rtp brief).", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created for OC-7 on 2026-09-19. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "PDF titled RTP Return Codes, created 2023-06-09, modified 2024-08-30", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "rtp-reject:src.iso20022-external-code-sets-2q2026", "id": "src.iso20022-external-code-sets-2q2026", "rail": "rtp-reject", "class": "RuleSource", "name": "ISO 20022 External Code Sets, 2Q2026 (ExternalStatusReason1Code)", "summary": "The ISO 20022 Registration Authority's published external code sets. Used only to tell whether a code is an ISO status reason code and what ISO's generic definition is; it says nothing about RTP usage.", "publisher": "ISO 20022 Registration Authority", "url": "https://www.iso20022.org/sites/default/files/media/file/ExternalCodeSets_JSON.zip", "source_class": "authoritative_primary", "kind": "code_set", "edition": "2Q2026 release, file 2Q2026_externalcodesets_v3.json", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The JSON file itself, downloaded and read 2026-09-19. Authoritative for ISO code names and generic definitions only, never for what a code means on RTP.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created for OC-7 on 2026-09-19. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "2Q2026 release, file 2Q2026_externalcodesets_v3.json", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:AC02", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC03", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC04", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC06", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC07", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC11", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC13", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC14", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AG01", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AG03", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AGNT", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM02", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM04", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM09", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM11", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM12", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM13", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM14", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE04", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE06", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE07", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE10", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE11", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE14", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE16", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE17", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:DS0H", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:DS24", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:DT04", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:DUPL", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:FF08", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:MD07", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:NARR", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC01", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC02", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC03", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC04", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK01", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK02", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK03", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TM01", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:src.oracle-us-rtp-reason-code-mapping", "id": "src.oracle-us-rtp-reason-code-mapping", "rail": "rtp-reject", "class": "RuleSource", "name": "US Real-Time Payments User Guide, Reason Code Mapping (Oracle Banking Payments 14.7)", "summary": "A software vendor's public user guide page. It lists the ISO reason codes a bank's system maps its own errors to when it rejects a US RTP payment, and marks each as used by the FI, by the CI, or both. It gives ISO's definitions, so it shows a code is used on RTP more than what it means there.", "publisher": "Oracle", "url": "https://docs.oracle.com/en/industries/financial-services/banking-payments/14.7.0.0.0/urtpu/reason-code-mapping.html", "source_class": "secondary", "kind": "vendor_documentation", "edition": "release 14.7.0.0.0, page created 2025-02-25", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The page itself, fetched and read 2026-09-19 (family D in the rtp brief). [Inference] FI means the receiving bank and CI the clearing infrastructure, here the RTP System; the page does not expand either.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created for OC-7 on 2026-09-19. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "release 14.7.0.0.0, page created 2025-02-25", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "rtp-reject:src.tch-rtp-operating-rules-2026-06-01", "id": "src.tch-rtp-operating-rules-2026-06-01", "rail": "rtp-reject", "class": "RuleSource", "name": "RTP Operating Rules, effective June 1, 2026", "summary": "TCH's public rulebook for the RTP network. Used for how a reject works (who may reject, on what grounds, the reason code duty, the response time-out, and that a rejected payment never settles). It does not list the reject codes; those sit in the RTP Technical Specifications, which Orca has not consulted.", "publisher": "The Clearing House Payments Company L.L.C.", "url": "https://www.theclearinghouse.org/-/media/New/TCH/Documents/Payment-Systems/RTP/RTP-Operating-Rules-Effective-June-1-2026pdf.pdf", "source_class": "authoritative_primary", "kind": "rulebook", "edition": "edition effective 2026-06-01, marked PUBLIC", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, opened and read 2026-09-19 (rules I.A, II.C, II.F, III.D, III.E, IV.A, V and VI.E).", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created for OC-7 on 2026-09-19. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "edition effective 2026-06-01, marked PUBLIC", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:rail.rtp-reject", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:exc.reject", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:exc.time-out-cancellation", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:role.receiving-participant", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:role.rtp-system", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:role.sending-participant", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:rule.reason-code-required", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:rule.receiver-reject-grounds", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:rule.reject-before-settlement", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:rule.reject-response-timeout", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:rule.system-reject-grounds", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:rule.system-reject-on-receipt", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "rtp-reject:txn.credit-transfer", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:txn.request-for-payment", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:src.trice-rtp-system-codes", "id": "src.trice-rtp-system-codes", "rail": "rtp-reject", "class": "RuleSource", "name": "RTP / FedNOW / ACH System Codes (Trice)", "summary": "A payments platform's public API reference. Its first list covers the codes an RTP transfer or request for payment may come back with; the FedNow and ACH lists on the same page are separate and not used.", "publisher": "Trice", "url": "https://triceapi.readme.io/reference/rtp-system-codes", "source_class": "secondary", "kind": "processor_developer_documentation", "edition": "live page, dateModified 2026-02-13", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The page itself, fetched and read 2026-09-19 (family B in the rtp brief). Orum publishes the same list word for word; that copy is not a second source.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created for OC-7 on 2026-09-19. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "live page, dateModified 2026-02-13", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "rtp-reject:txn.credit-transfer", "id": "txn.credit-transfer", "rail": "rtp-reject", "class": "TransactionType", "name": "RTP credit transfer (pacs.008)", "summary": "A payment message by which a sending participant instructs a receiving participant to pay a fixed US dollar amount to the receiver; credit push only, up to the network limit of $10,000,000. The ISO 20022 message is pacs.008 (Cross River Bank names it; the Operating Rules speak only of a payment message).", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "rtp-reject:src.tch-rtp-operating-rules-2026-06-01", "section": "Rule I.A.58 (payment message); Rule II.C.2 (transaction limit)", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RTP Operating Rules effective 2026-06-01, Rules I.A.58 and II.C.2, read 2026-09-19. The pacs.008 message name is from the Cross River Bank request and response codes page, read 2026-09-19. sec_code is null: RTP has no standard entry class codes.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted for OC-7 on 2026-09-19 from the RTP Operating Rules edition effective 2026-06-01; no rule change identified since.", "source_edition": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:rule.reason-code-required", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:rule.receiver-reject-grounds", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:rule.reject-before-settlement", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:rule.reject-response-timeout", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:rule.system-reject-grounds", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:rule.system-reject-on-receipt", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:txn.request-for-payment", "id": "txn.request-for-payment", "rail": "rtp-reject", "class": "TransactionType", "name": "RTP request for payment (pain.013)", "summary": "A message by which one participant's customer asks a customer of another participant to pay. It moves no money and is not a debit; any payment it leads to is a separate credit transfer. Trice lists its reject codes together with those of the credit transfer. The ISO 20022 message name pain.013 is from Cross River Bank's page, not from a TCH document read.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": false, "relations": [ { "type": "sourced_from", "to": "rtp-reject:src.tch-rtp-operating-rules-2026-06-01", "section": "Rule I.A.78 (definition); Rule VII.B.1", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "RTP Operating Rules effective 2026-06-01, Rules I.A.78 and VII.B.1, read 2026-09-19; Cross River Bank request and response codes page for the message name. directions is credit because the payment asked for would be a credit; the request itself moves nothing, which value false records.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted for OC-7 on 2026-09-19 from the RTP Operating Rules edition effective 2026-06-01; no rule change identified since.", "source_edition": "TCH RTP Operating Rules, edition effective 2026-06-01 (marked PUBLIC), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "rtp-reject:1100", "id": "1100", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Depends on the reason given; the rejected payment never settled." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.crossriver-instant-error-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:NARR", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.crossriver-instant-error-codes", "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": "rtp-reject:src.trice-rtp-system-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:NARR", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:9912", "id": "9912", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Only as a new payment message, and only once the participant or service is available again [Inference]; the rejected payment never settled." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.crossriver-instant-error-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-error-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.crossriver-instant-error-codes", "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": "rtp-reject:src.trice-rtp-system-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "rtp-reject:9914", "id": "9914", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-error-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-error-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.crossriver-instant-error-codes", "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": "rtp-reject:src.trice-rtp-system-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "rtp-reject:9934", "id": "9934", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Only as a new payment message, and only once the participant or service is available again [Inference]; the rejected payment never settled." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.crossriver-instant-error-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-error-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.crossriver-instant-error-codes", "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": "rtp-reject:src.trice-rtp-system-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "rtp-reject:9946", "id": "9946", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Only as a new payment message, and only once the participant or service is available again [Inference]; the rejected payment never settled." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.crossriver-instant-error-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-error-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:9947", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.crossriver-instant-error-codes", "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": "rtp-reject:src.trice-rtp-system-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:9947", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:9956", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:9957", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:9947", "id": "9947", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Only as a new payment message, and only once the participant or service is available again [Inference]; the rejected payment never settled." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.crossriver-instant-error-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-error-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:9946", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.crossriver-instant-error-codes", "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": "rtp-reject:src.trice-rtp-system-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:9946", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:9948", "id": "9948", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Only as a new payment message, and only once the participant or service is available again [Inference]; the rejected payment never settled." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.crossriver-instant-error-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-error-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.crossriver-instant-error-codes", "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": "rtp-reject:src.trice-rtp-system-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "rtp-reject:9952", "id": "9952", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-error-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-error-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.crossriver-instant-error-codes", "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": "rtp-reject:src.trice-rtp-system-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "rtp-reject:9953", "id": "9953", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-error-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-error-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.crossriver-instant-error-codes", "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": "rtp-reject:src.trice-rtp-system-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "rtp-reject:9956", "id": "9956", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Only as a new payment message, and only once the participant or service is available again [Inference]; the rejected payment never settled." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-error-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-error-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:9946", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.crossriver-instant-error-codes", "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": "rtp-reject:src.trice-rtp-system-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "rtp-reject:9957", "id": "9957", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Only as a new payment message, and only once the participant or service is available again [Inference]; the rejected payment never settled." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-error-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-error-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:9946", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.crossriver-instant-error-codes", "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": "rtp-reject:src.trice-rtp-system-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "rtp-reject:9964", "id": "9964", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-error-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-error-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.crossriver-instant-error-codes", "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": "rtp-reject:src.trice-rtp-system-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "rtp-reject:AC02", "id": "AC02", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" }, { "source": "rtp-reject:src.cuanswers-rtp-return-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:AC13", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:AC03", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.trice-rtp-system-codes", "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": "rtp-reject:src.cuanswers-rtp-return-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:AC03", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC13", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:AC03", "id": "AC03", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" }, { "source": "rtp-reject:src.cuanswers-rtp-return-codes" }, { "source": "rtp-reject:src.oracle-us-rtp-reason-code-mapping" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "evidence": [ { "source": "rtp-reject:src.oracle-us-rtp-reason-code-mapping" } ], "note": "[Inference] The Oracle page marks this code as used by the FI and not the CI, read here as the receiving bank and not the RTP System.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:AC04", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:AC07", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:AC14", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:BE06", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:AC02", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.trice-rtp-system-codes", "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": "rtp-reject:src.cuanswers-rtp-return-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:AC02", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC04", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE06", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:AC04", "id": "AC04", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Do not send again to the same account. Get new account details from the receiver and send a new payment." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" }, { "source": "rtp-reject:src.cuanswers-rtp-return-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:AC07", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:AC03", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.trice-rtp-system-codes", "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": "rtp-reject:src.cuanswers-rtp-return-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:AC03", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC07", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:AC06", "id": "AC06", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Not to the same account while the block stands. The rejected payment never settled." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" }, { "source": "rtp-reject:src.cuanswers-rtp-return-codes" }, { "source": "rtp-reject:src.oracle-us-rtp-reason-code-mapping" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "evidence": [ { "source": "rtp-reject:src.oracle-us-rtp-reason-code-mapping" } ], "note": "[Inference] The Oracle page marks this code as used by the FI and not the CI, read here as the receiving bank and not the RTP System.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.trice-rtp-system-codes", "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": "rtp-reject:src.cuanswers-rtp-return-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "rtp-reject:AC07", "id": "AC07", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Do not send again to the same account. Get new account details and send a new payment." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.oracle-us-rtp-reason-code-mapping" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "evidence": [ { "source": "rtp-reject:src.oracle-us-rtp-reason-code-mapping" } ], "note": "[Inference] The Oracle page marks this code as used by the FI and not the CI, read here as the receiving bank and not the RTP System.", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:AC04", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.crossriver-instant-request-response-codes", "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": "rtp-reject:src.oracle-us-rtp-reason-code-mapping", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:AC03", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC04", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:AC11", "id": "AC11", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" }, { "source": "rtp-reject:src.cuanswers-rtp-return-codes" }, { "source": "rtp-reject:src.oracle-us-rtp-reason-code-mapping" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "evidence": [ { "source": "rtp-reject:src.oracle-us-rtp-reason-code-mapping" } ], "note": "[Inference] The Oracle page marks this code as used by the FI and not the CI, read here as the receiving bank and not the RTP System.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:AM11", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.trice-rtp-system-codes", "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": "rtp-reject:src.cuanswers-rtp-return-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:AM11", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:AC13", "id": "AC13", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" }, { "source": "rtp-reject:src.cuanswers-rtp-return-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:AC02", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:AC14", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.trice-rtp-system-codes", "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": "rtp-reject:src.cuanswers-rtp-return-codes", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:AC02", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC14", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:AC14", "id": "AC14", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" }, { "source": "rtp-reject:src.cuanswers-rtp-return-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:AC13", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:AG01", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.trice-rtp-system-codes", "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": "rtp-reject:src.cuanswers-rtp-return-codes", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:AC03", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AC13", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AG01", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:AG01", "id": "AG01", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Not to the same account. Pay to an account that can take RTP payments, or by another rail." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" }, { "source": "rtp-reject:src.cuanswers-rtp-return-codes" }, { "source": "rtp-reject:src.oracle-us-rtp-reason-code-mapping" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "evidence": [ { "source": "rtp-reject:src.oracle-us-rtp-reason-code-mapping" } ], "note": "[Inference] The Oracle page marks this code as used by the FI and not the CI, read here as the receiving bank and not the RTP System.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:AG03", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:AC14", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:NOAT", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.trice-rtp-system-codes", "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": "rtp-reject:src.cuanswers-rtp-return-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:AC14", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AG03", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:NOAT", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:AG03", "id": "AG03", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Not to the same account for the same type of transaction." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" }, { "source": "rtp-reject:src.cuanswers-rtp-return-codes" }, { "source": "rtp-reject:src.oracle-us-rtp-reason-code-mapping" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:AG01", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:NOAT", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.trice-rtp-system-codes", "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": "rtp-reject:src.cuanswers-rtp-return-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:AG01", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:NOAT", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:AGNT", "id": "AGNT", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" }, { "source": "rtp-reject:src.cuanswers-rtp-return-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:RC02", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:RC04", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.trice-rtp-system-codes", "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": "rtp-reject:src.cuanswers-rtp-return-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:RC04", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:AM02", "id": "AM02", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Not for the same amount. Pay the amount by another rail or as the parties agree [Inference]." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" }, { "source": "rtp-reject:src.cuanswers-rtp-return-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:AM13", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:AM14", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.trice-rtp-system-codes", "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": "rtp-reject:src.cuanswers-rtp-return-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:AM13", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM14", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:AM04", "id": "AM04", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "A new payment once funds are available [Inference]; the rejected payment never settled." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" }, { "source": "rtp-reject:src.cuanswers-rtp-return-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.trice-rtp-system-codes", "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": "rtp-reject:src.cuanswers-rtp-return-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "rtp-reject:AM09", "id": "AM09", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" }, { "source": "rtp-reject:src.cuanswers-rtp-return-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:AM12", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.trice-rtp-system-codes", "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": "rtp-reject:src.cuanswers-rtp-return-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:AM12", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:AM11", "id": "AM11", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" }, { "source": "rtp-reject:src.oracle-us-rtp-reason-code-mapping" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:AC11", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.trice-rtp-system-codes", "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": "rtp-reject:src.oracle-us-rtp-reason-code-mapping", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:AC11", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:AM12", "id": "AM12", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" }, { "source": "rtp-reject:src.cuanswers-rtp-return-codes" }, { "source": "rtp-reject:src.oracle-us-rtp-reason-code-mapping" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:AM09", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.trice-rtp-system-codes", "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": "rtp-reject:src.cuanswers-rtp-return-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:AM09", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:AM13", "id": "AM13", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Not for the same amount on RTP." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" }, { "source": "rtp-reject:src.cuanswers-rtp-return-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:AM02", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:AM14", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.trice-rtp-system-codes", "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": "rtp-reject:src.cuanswers-rtp-return-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:AM02", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM14", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:AM14", "id": "AM14", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Not for the same amount while the limit stands." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" }, { "source": "rtp-reject:src.cuanswers-rtp-return-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:AM02", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:AM13", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.trice-rtp-system-codes", "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": "rtp-reject:src.cuanswers-rtp-return-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:AM02", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AM13", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:BE04", "id": "BE04", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" }, { "source": "rtp-reject:src.cuanswers-rtp-return-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:BE07", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.trice-rtp-system-codes", "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": "rtp-reject:src.cuanswers-rtp-return-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:BE07", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:BE06", "id": "BE06", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Not with the same details. Confirm who and where the receiver is first." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" }, { "source": "rtp-reject:src.cuanswers-rtp-return-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:AC03", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:MD07", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.trice-rtp-system-codes", "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": "rtp-reject:src.cuanswers-rtp-return-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:AC03", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:MD07", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:BE07", "id": "BE07", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" }, { "source": "rtp-reject:src.cuanswers-rtp-return-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:BE04", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.trice-rtp-system-codes", "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": "rtp-reject:src.cuanswers-rtp-return-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:BE04", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:BE10", "id": "BE10", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" }, { "source": "rtp-reject:src.cuanswers-rtp-return-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:BE11", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.trice-rtp-system-codes", "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": "rtp-reject:src.cuanswers-rtp-return-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:BE11", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:BE11", "id": "BE11", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" }, { "source": "rtp-reject:src.cuanswers-rtp-return-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:BE10", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:BE14", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.trice-rtp-system-codes", "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": "rtp-reject:src.cuanswers-rtp-return-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:BE10", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:BE14", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:BE14", "id": "BE14", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:BE11", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.crossriver-instant-request-response-codes", "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": "rtp-reject:src.trice-rtp-system-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:BE11", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:BE16", "id": "BE16", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" }, { "source": "rtp-reject:src.cuanswers-rtp-return-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:BE17", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.trice-rtp-system-codes", "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": "rtp-reject:src.cuanswers-rtp-return-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:BE17", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:BE17", "id": "BE17", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" }, { "source": "rtp-reject:src.cuanswers-rtp-return-codes" }, { "source": "rtp-reject:src.oracle-us-rtp-reason-code-mapping" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "evidence": [ { "source": "rtp-reject:src.oracle-us-rtp-reason-code-mapping" } ], "note": "[Inference] The Oracle page marks this code as used by the FI and not the CI, read here as the receiving bank and not the RTP System.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:BE16", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.trice-rtp-system-codes", "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": "rtp-reject:src.cuanswers-rtp-return-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:BE16", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:DS0H", "id": "DS0H", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Only as a new payment authorized by someone entitled to sign [Inference]." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.crossriver-instant-request-response-codes", "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": "rtp-reject:src.trice-rtp-system-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "rtp-reject:DS24", "id": "DS24", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Only as a new payment message that meets the requirements for new messages (Operating Rules IV.A.4)." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.time-out-cancellation", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" }, { "source": "rtp-reject:src.cuanswers-rtp-return-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.trice-rtp-system-codes", "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": "rtp-reject:src.cuanswers-rtp-return-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "rtp-reject:DT04", "id": "DT04", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" }, { "source": "rtp-reject:src.cuanswers-rtp-return-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.trice-rtp-system-codes", "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": "rtp-reject:src.cuanswers-rtp-return-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "rtp-reject:DUPL", "id": "DUPL", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Do not resend: the payment already exists. Check the status of the first one." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" }, { "source": "rtp-reject:src.cuanswers-rtp-return-codes" }, { "source": "rtp-reject:src.oracle-us-rtp-reason-code-mapping" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-return-request:DUPL", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.trice-rtp-system-codes", "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": "rtp-reject:src.cuanswers-rtp-return-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "rtp-reject:FF08", "id": "FF08", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.crossriver-instant-request-response-codes", "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": "rtp-reject:src.trice-rtp-system-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "rtp-reject:MD07", "id": "MD07", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Do not send again to this receiver." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" }, { "source": "rtp-reject:src.cuanswers-rtp-return-codes" }, { "source": "rtp-reject:src.oracle-us-rtp-reason-code-mapping" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "evidence": [ { "source": "rtp-reject:src.oracle-us-rtp-reason-code-mapping" } ], "note": "[Inference] The Oracle page marks this code as used by the FI and not the CI, read here as the receiving bank and not the RTP System.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:BE06", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.trice-rtp-system-codes", "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": "rtp-reject:src.cuanswers-rtp-return-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:BE06", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:NARR", "id": "NARR", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Depends on the reason given; the rejected payment never settled." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" }, { "source": "rtp-reject:src.cuanswers-rtp-return-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:1100", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.trice-rtp-system-codes", "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": "rtp-reject:src.cuanswers-rtp-return-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:1100", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:NOAT", "id": "NOAT", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Not the same message type to the same account." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.crossriver-instant-error-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:AG03", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:AG01", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.crossriver-instant-error-codes", "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": "rtp-reject:src.trice-rtp-system-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:AG01", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:AG03", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:RC01", "id": "RC01", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:RC02", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:RC03", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:RC04", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.crossriver-instant-request-response-codes", "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": "rtp-reject:src.trice-rtp-system-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:RC02", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:RC02", "id": "RC02", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:RC01", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:RC03", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:RC04", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.crossriver-instant-request-response-codes", "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": "rtp-reject:src.trice-rtp-system-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:AGNT", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC01", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC03", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC04", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:RC03", "id": "RC03", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:RC04", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:RC02", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.crossriver-instant-request-response-codes", "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": "rtp-reject:src.trice-rtp-system-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:RC01", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC02", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC04", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:RC04", "id": "RC04", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" }, { "source": "rtp-reject:src.cuanswers-rtp-return-codes" }, { "source": "rtp-reject:src.oracle-us-rtp-reason-code-mapping" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:RC03", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:RC02", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:AGNT", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.trice-rtp-system-codes", "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": "rtp-reject:src.cuanswers-rtp-return-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:AGNT", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC01", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC02", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:RC03", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:TK01", "id": "TK01", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer", "rtp-reject:txn.request-for-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:TK02", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:TK03", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.crossriver-instant-request-response-codes", "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": "rtp-reject:src.trice-rtp-system-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:TK02", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK03", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK04", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK05", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK06", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK07", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK08", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:TK02", "id": "TK02", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer", "rtp-reject:txn.request-for-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:TK01", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:TK03", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.crossriver-instant-request-response-codes", "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": "rtp-reject:src.trice-rtp-system-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:TK01", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK03", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:TK03", "id": "TK03", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer", "rtp-reject:txn.request-for-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:TK01", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:TK02", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.crossriver-instant-request-response-codes", "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": "rtp-reject:src.trice-rtp-system-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "rtp-reject:TK01", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "rtp-reject:TK02", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "rtp-reject:TK04", "id": "TK04", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer", "rtp-reject:txn.request-for-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:TK01", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.crossriver-instant-request-response-codes", "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": "rtp-reject:src.trice-rtp-system-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "rtp-reject:TK05", "id": "TK05", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer", "rtp-reject:txn.request-for-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:TK01", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.crossriver-instant-request-response-codes", "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": "rtp-reject:src.trice-rtp-system-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "rtp-reject:TK06", "id": "TK06", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Not for the same amount with the same token." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer", "rtp-reject:txn.request-for-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:TK01", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.crossriver-instant-request-response-codes", "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": "rtp-reject:src.trice-rtp-system-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "rtp-reject:TK07", "id": "TK07", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Not with the same token." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer", "rtp-reject:txn.request-for-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:TK01", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.crossriver-instant-request-response-codes", "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": "rtp-reject:src.trice-rtp-system-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "rtp-reject:TK08", "id": "TK08", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Not with the same token while it is suspended." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer", "rtp-reject:txn.request-for-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:TK01", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.crossriver-instant-request-response-codes", "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": "rtp-reject:src.trice-rtp-system-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "rtp-reject:TM01", "id": "TM01", "rail": "rtp-reject", "class": "ReasonCode", "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, "guidance": "Send a new payment message once the fault is fixed; the rejected payment never settled, so there is nothing to reverse or return." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "rtp-reject:txn.credit-transfer" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "rtp-reject:exc.reject", "evidence": [ { "source": "rtp-reject:src.crossriver-instant-request-response-codes" }, { "source": "rtp-reject:src.trice-rtp-system-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.receiving-participant", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "rtp-reject:role.rtp-system", "note": "[Inference] No public source read says which side sends this code; both possible senders are linked.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-before-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reason-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.receiver-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.reject-response-timeout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-grounds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "rtp-reject:rule.system-reject-on-receipt", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp-reject:src.iso20022-external-code-sets-2q2026", "note": "The ISO code set that lists this code, for its generic meaning only; v0 has no typed link from a code to the code set it comes from.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "rtp-reject:src.crossriver-instant-request-response-codes", "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": "rtp-reject:src.trice-rtp-system-codes", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rail.uk-fps", "id": "rail.uk-fps", "class": "Rail", "rail": "uk-fps", "name": "Faster Payments (UK)", "governing_authority": "Pay.UK Limited", "country": "GB", "currency": "GBP", "operators": [ "Pay.UK Limited", "Vocalink Limited (central infrastructure, under outsourcing from Pay.UK)" ], "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" ], "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "sections 3, 4, 5 and 6", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-pfmi-self-assessment-2025", "section": "2, 2.1 and 2.2.2", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "clause 9.1", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps-reject:rail.uk-fps-reject", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps-return:rail.uk-fps-return", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "source_class": null, "effective_status_reason": null, "used_by": [ { "from": "uk-fps-reject:rail.uk-fps-reject", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:rail.uk-fps-return", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:exc.app-scam-claim", "id": "exc.app-scam-claim", "rail": "uk-fps", "class": "Exception", "name": "FPS APP scam claim", "summary": "A consumer tells the provider that holds the account they paid from that they were deceived into authorising one or more Faster Payments. The provider tells the receiving providers within two business hours, lets them respond, assesses whether the payments are reimbursable, and if they are, pays the victim in full up to the ceiling and less any excess. It then claims half back, apportioned, from the receiving providers. Anything recovered from the fraudster afterwards is shared so that nobody gets back more than they paid out. It is not a chargeback and not a scheme reversal: no Faster Payment is undone and settlement finality is untouched.", "money_moves": true, "outcome": "Where the payments are reimbursable, the victim is paid in full up to the ceiling, less any excess, within five business days unless the clock is stopped, and in any case the claim is decided and closed by the end of the 35th business day. The receiving providers pay the sending provider half of that amount between them. Where the payments are not reimbursable, the consumer is told in writing with a summary of the reasons and the claim is closed with nothing owed by the receiving side.", "relations": [ { "type": "initiated_by", "to": "uk-fps:role.consumer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "uk-fps:role.sending-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "clauses 3.1 to 3.12, 4.1 to 4.15, 5.1 to 5.9 and 6.1 to 6.5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.psr-specific-direction-20-july-2024", "section": "paragraphs 3.1 to 3.3 and 4.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "FPS Reimbursement Rules Schedule 4 v3.0, sections 3 to 6; PSR Specific Direction 20 (July 2024), paragraphs 3.1 to 3.3 and 4.1. Both read 2026-09-20.", "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).", "source_edition": "FPS Reimbursement Rules, Schedule 4, v3.0 dated 26 September 2024, read 2026-09-20, together with PSR Specific Direction 20 (July 2024) and the two PSR notices of value, all read the same day.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the full claim lifecycle: notification within two business hours, the opportunity to respond, assessment, reimbursement up to the ceiling less any excess, the half share contribution, and repatriation apportionment." }, { "source": "uk-fps:src.psr-specific-direction-20-july-2024", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the reimbursement requirement and its 7 October 2024 implementation date." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:rule.app-reimbursement-requirement", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.claim-decided-and-closed-by-the-35th-business-day", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.claim-excess-up-to-100", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.consumer-standard-of-caution-exception", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.contribution-paid-within-five-business-days", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.maximum-level-of-reimbursement", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.no-excess-for-a-vulnerable-consumer", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.notify-the-receiving-provider-within-two-business-hours", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.other-grounds-a-claim-is-not-reimbursable", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.outcome-must-be-told-to-the-consumer-in-writing", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.receiving-provider-answers-an-information-request-by-the-25th-business-day", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.receiving-provider-chooses-what-to-volunteer-and-when-to-repatriate", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.receiving-provider-may-respond-within-three-business-days", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.reimbursable-contribution-is-half-apportioned", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.reimburse-within-five-business-days", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.reimbursement-does-not-affect-finality", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.reimbursement-overrides-the-wrong-identifier-defence", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.reimbursement-rules-bind-non-members", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.repatriation-apportionment", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.repatriation-within-three-business-days-of-concluding-investigations", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.sending-provider-judges-the-scam-claim", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.stop-the-clock-grounds", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.thirteen-month-reporting-limit", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.uk-to-uk-scope-of-the-reimbursement-requirement", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.voluntary-reimbursement-is-outside-the-regime", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:exc.bank-error-recovery", "id": "exc.bank-error-recovery", "rail": "uk-fps", "class": "Exception", "name": "Bank Error Recovery (BER)", "summary": "The process a directly connected participant may use when it has sent a large number of payments in error: it sends a recovery file to the participants that received them. A settling or non-settling participant may invoke it for an indirect agency it sponsors. Like Credit Payment Recovery it sits in the FPS Procedures, which Pay.UK does not publish, and nothing read says the receiving side must comply.", "money_moves": true, "outcome": "The receiving participants are asked to return the payments sent in error. Whether they must is not stated in any public document read [Unverified].", "relations": [ { "type": "initiated_by", "to": "uk-fps:role.sending-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "uk-fps:role.receiving-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "Required Elements, Bank Error Recover", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, the Bank Error Recover row of the Required Elements table, read 2026-09-20. The process document itself is in the FPS Procedures, which Pay.UK does not publish.", "confidence": "low" }, "currency": { "effective_since": "Unknown: the public documents read do not date the exception paths", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:rule.bank-error-recovery-for-payments-sent-in-bulk-by-mistake", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:exc.credit-payment-recovery", "id": "exc.credit-payment-recovery", "rail": "uk-fps", "class": "Exception", "name": "Credit Payment Recovery (CPR)", "summary": "The industry process for trying to get back a payment that reached the wrong account because the customer or the bank made a mistake. An indirect agency may join it directly or use it through a recovery sponsoring participant. It is a recovery attempt outside the message flow, not a scheme reversal: nothing read says the receiving institution must return the money, and Pay.UK does not publish the process itself.", "money_moves": true, "outcome": "The sending side may or may not get the money back. Whether the receiving institution is obliged to return it is not stated in any public document read [Unverified].", "relations": [ { "type": "initiated_by", "to": "uk-fps:role.sending-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "uk-fps:role.receiving-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "Required Elements, Credit Payment Recovery", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, the Credit Payment Recovery row of the Required Elements table, read 2026-09-20. The process document itself is in the FPS Procedures, which Pay.UK does not publish.", "confidence": "low" }, "currency": { "effective_since": "Unknown: the public documents read do not date the exception paths", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:rule.credit-payment-recovery-is-not-a-reversal", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:exc.rejection", "id": "exc.rejection", "rail": "uk-fps", "class": "Exception", "name": "Rejection", "summary": "The receiving institution answers a payment with a rejection instead of an acceptance. It is one of the three answers a receiving institution may give, and the payment does not reach the payee. The answer must carry a rejection code from the list in the FPS Procedures, which Pay.UK does not publish. The central infrastructure can also reject a payment of its own motion, for instance one above the system value ceiling.", "money_moves": false, "outcome": "No money moves to the payee. The sending institution learns the fate of the payment and must tell its customer.", "relations": [ { "type": "initiated_by", "to": "uk-fps:role.receiving-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "uk-fps:role.receiving-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "Required Elements, Availability of Funds to the Beneficiary, Fate of Payment, Limits", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-certainty-of-fate-rule-clarification-2026-01", "section": "annex, rules 6.2 and 10.1", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps-reject:exc.rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, Required Elements (Availability of Funds to the Beneficiary, Fate of Payment, Limits); Certainty of Fate annex, rules 6.2 and 10.1. Both read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date the exception paths", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms rejection as one of three responses, that no money reaches the payee, and that the infrastructure itself may reject a payment above the system value ceiling." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:exc.scheme-return-payment", "type": "follows", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.receiving-institution-decides-in-seconds", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.system-value-ceiling-one-million", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:exc.rejection", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:exc.return-payment", "id": "exc.return-payment", "rail": "uk-fps", "class": "Exception", "name": "Return Payment", "summary": "A payment was accepted and then could not be made available to the payee, so the funds go back. Nothing is reversed: the receiving institution raises a new credit payment that references the original and carries a return reason. It must go within one to three working days of the original payment, and where the whole amount cannot be returned within transaction limits the two institutions must agree how the funds go back. A partial return cannot use this path at all and has to be made as a new payment with the originator's agreement.", "money_moves": true, "outcome": "A fresh credit payment carrying a return reason reaches the original sender's institution. The original payment stands and is never reversed.", "relations": [ { "type": "initiated_by", "to": "uk-fps:role.receiving-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "uk-fps:role.receiving-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "section 5.4; Required Elements, Returns", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-certainty-of-fate-rule-clarification-2026-01", "section": "annex, rule 10.1", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps-return:exc.return-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, section 5.4 and the Returns row of the Required Elements table; Certainty of Fate annex, rule 10.1. Both read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date the exception paths", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the Return Payment mechanics: a new credit referencing the original, the one to three working day window, and the transaction limit agreement duty." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:rule.partial-return-needs-the-originators-agreement", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.return-blocked-by-a-transaction-limit-must-be-agreed", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.return-payment-is-a-new-payment", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.return-payment-within-1-to-3-working-days", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:exc.return-payment", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:rule.return-reason-required", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:exc.scheme-return-payment", "id": "exc.scheme-return-payment", "rail": "uk-fps", "class": "Exception", "name": "Scheme Return Payment", "summary": "An asynchronous payment, meaning a forward dated payment, a standing order or a Direct Corporate Access payment, was received by a directly connected participant and rejected. The central infrastructure then sends the funds back itself. No participant can raise this return.", "money_moves": true, "outcome": "The central infrastructure returns the funds for the rejected asynchronous payment.", "relations": [ { "type": "initiated_by", "to": "uk-fps:role.central-infrastructure-provider", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "follows", "to": "uk-fps:exc.rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "section 5.5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, section 5.5, read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date the exception paths", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that only the central infrastructure sends a Scheme Return Payment, for a rejected asynchronous payment." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:rule.scheme-return-sent-only-by-the-infrastructure", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:mandate.standing-order-instruction", "id": "mandate.standing-order-instruction", "rail": "uk-fps", "class": "Mandate", "name": "Standing order instruction", "summary": "The payer's own standing instruction to its own payment service provider to push a set amount to a named payee at a stated interval. It is not a debit mandate and it is nothing like a direct debit authority: Faster Payments carries no debit pull at all, so nobody outside the payer's provider holds it, and the central infrastructure never sees it. The instruction only produces a payment on the due date, when the provider submits a standing order payment; until then there is nothing on the rail. The payer may ask the provider to cancel it, and the provider may do so at any time before the payment is submitted. Where a payee's account has been switched under the Current Account Switch Service, the central infrastructure redirects the payment and the sending participant must then update the payer's standing instruction within the permitted timescale.", "form": "A standing instruction the payer gives its own provider through that provider's own channel. Neither the form nor the wording is set by any public document read; how the instruction is captured and evidenced is each provider's own matter.", "scope": [ "a fixed amount to a single named payee, identified by sort code and account number", "repeating on a schedule the payer sets, executed only on weekdays excluding public holidays in England and Wales", "held by the payer's own provider and submitted to the central infrastructure only on the due date" ], "relations": [ { "type": "given_by", "to": "uk-fps:role.consumer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "given_to", "to": "uk-fps:role.sending-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "authorises", "to": "uk-fps:txn.standing-order-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, section 5.2 (what a standing order payment is, when it may be executed, cancellation and retry) and the Redirections row of the Required Elements table; Pay.UK 2025 PFMI self-assessment, section 2.2.2 (all FPS payment types are credit pushes). Both read 2026-09-20. No public document read describes how the instruction itself is given, kept, evidenced or disputed, so form and scope are drawn from what the payment type requires rather than from a rule about the instruction [Inference].", "confidence": "low" }, "currency": { "effective_since": "Unknown: the public documents read do not date the standing order arrangement", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "au-npp:mandate.authorised-payment-mandate", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:role.bank-of-england", "id": "role.bank-of-england", "rail": "uk-fps", "class": "Role", "name": "Bank of England", "summary": "Two roles at once on this rail. As settlement service provider it holds the reserve, settlement and pre-funding accounts of settling participants and settles the net positions over its real time gross settlement infrastructure in central bank money. As supervisor, because Faster Payments is recognised by HM Treasury under section 184 of the Banking Act 2009, its Financial Market Infrastructure Directorate supervises Pay.UK's operation of the system.", "kind": "authority", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-pfmi-self-assessment-2025", "section": "2.1 and 2.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "sections 4.1 and 6", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Pay.UK 2025 PFMI self-assessment, sections 2.1 and 2.2; Faster Payments System Principles v11, sections 4.1 and 6. Both read 2026-09-20. Role.kind holds one value and this Role fills two functions; settlement service provider is the one the corpus uses most, and supervisor is recorded here in words.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date the participation framework", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-pfmi-self-assessment-2025", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the Bank's role holding settlement accounts and settling net positions, and its supervisory role under section 184 of the Banking Act 2009." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:rule.deferred-net-settlement-three-times-each-working-day", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.designated-for-settlement-finality", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.net-settlement-final-at-rtgs-timestamp", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.pre-funded-account-equal-to-net-sender-cap", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.settlement-in-central-bank-money-at-boe", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:role.central-infrastructure-provider", "id": "role.central-infrastructure-provider", "rail": "uk-fps", "class": "Role", "name": "Vocalink, the FPS central infrastructure provider", "summary": "The company that runs the central infrastructure for Faster Payments under outsourcing from Pay.UK, and has done since 2008. It routes and clears every payment, refers each one to the Current Account Switch Service redirection table, nets participants' positions for settlement, hosts the Direct Corporate Access module and the file input module, and charges the connectivity and transaction fees participants pay. It is not the rule writer, and its behaviour is not a scheme rule.", "kind": "service_provider", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-pfmi-self-assessment-2025", "section": "2 and 2.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "sections 5.6, 10.1, 10.2, 12 and 12.1; Required Elements, Redirections", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Pay.UK 2025 PFMI self-assessment, sections 2 and 2.2; Faster Payments System Principles v11, sections 5.6, 10.1, 10.2, 12 and 12.1 and the Redirections row of the Required Elements table. Both read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date the participation framework", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-pfmi-self-assessment-2025", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms Vocalink as the central infrastructure provider under outsourcing from Pay.UK since 2008." }, { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms Vocalink's routing, redirection, netting, DCA and FIM hosting roles." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:exc.scheme-return-payment", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.cass-redirection-happens-inside-the-infrastructure", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.deferred-net-settlement-three-times-each-working-day", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.scheme-return-sent-only-by-the-infrastructure", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.system-value-ceiling-one-million", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:role.fps-central-infrastructure", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:role.consumer", "id": "role.consumer", "rail": "uk-fps", "class": "Role", "name": "Consumer (reimbursement rules)", "summary": "The service user the reimbursement rules protect: an individual, a microenterprise employing fewer than ten people whose annual turnover or balance sheet total is no more than two million euro, or a charity whose annual income is under one million pounds. A Consumer who has made one or more scam payments is called a Victim. The rules expect the Consumer to heed an intervention, report promptly, answer reasonable information requests and agree to a report to the police, and a Consumer who falls short of those standards through gross negligence may lose the right to be reimbursed unless vulnerability had a material effect.", "kind": "party", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "clauses 3.6, 3.11 and 10.4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "FPS Reimbursement Rules Schedule 4 v3.0, clauses 3.6 and 3.11 and the definitions of Consumer, Victim and Vulnerable Consumer in clause 10.4, read 2026-09-20.", "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).", "source_edition": "FPS Reimbursement Rules, Schedule 4, v3.0 dated 26 September 2024, read 2026-09-20, together with PSR Specific Direction 20 (July 2024) and the two PSR notices of value, all read the same day.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the definitions of Consumer, Victim and Vulnerable Consumer, and the standard of caution the rules expect a Consumer to meet." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:exc.app-scam-claim", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:mandate.standing-order-instruction", "type": "given_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.confirmation-of-payee-gives-the-payer-four-outcomes", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.consumer-standard-of-caution-exception", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.other-legal-regimes-are-not-displaced", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.providers-must-tell-consumers-and-change-their-terms", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.thirteen-month-reporting-limit", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:role.dcnsp", "id": "role.dcnsp", "rail": "uk-fps", "class": "Role", "name": "Directly Connected Non-Settling Participant (DCNSP)", "summary": "A payment service provider connected straight to the FPS central infrastructure that does not settle for itself. A sponsoring settling participant authorises each of its debits and credits in near real time and manages its settlement at the Bank of England. It carries the same sending and receiving obligations as a settling participant, including authorisation under the Payment Services Regulations 2017, except the requirement to hold settlement facilities at the Bank of England.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "section 4.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-pfmi-self-assessment-2025", "section": "2.2.2", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, section 4.2 and its footnote; Pay.UK 2025 PFMI self-assessment, section 2.2.2. Both read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date the participation framework", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the DCNSP's sponsored settlement and shared obligations with a settling participant except the Bank of England settlement facilities requirement." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:rule.dcnsp-and-indirect-access", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.dcnsp-settles-through-its-sponsor", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.sort-code-directory-must-be-refreshed-weekly", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:role.dcsp", "id": "role.dcsp", "rail": "uk-fps", "class": "Role", "name": "Directly Connected Settling Participant (DCSP)", "summary": "A payment service provider connected straight to the FPS central infrastructure that settles for itself. It must hold reserve or settlement accounts at the Bank of England, be authorised under the Payment Services Regulations 2017, hold or be eligible for at least one sort code, meet the scheme's technical and operational requirements, and comply with the FPS Rules. It sets its own net sender cap and holds cash equal to that cap in a separate pre-funded account. It may also sponsor non-settling participants and indirect agencies.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "sections 4.1, 4.2, 4.3 and 6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-pfmi-self-assessment-2025", "section": "2.2.2", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, sections 4.1 to 4.3 and section 6; Pay.UK 2025 PFMI self-assessment, section 2.2.2. Both read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date the participation framework", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the DCSP's eligibility requirements, net sender cap and pre funded account duties, and its role sponsoring non-settling participants and indirect agencies." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:rule.dcsp-eligibility", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.deferred-net-settlement-three-times-each-working-day", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.net-sender-cap-set-by-each-participant", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.net-settlement-final-at-rtgs-timestamp", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.onboarding-takes-9-to-12-months", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.pre-funded-account-equal-to-net-sender-cap", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.settlement-in-central-bank-money-at-boe", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.sort-code-directory-must-be-refreshed-weekly", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:role.directed-psp", "id": "role.directed-psp", "rail": "uk-fps", "class": "Role", "name": "Directed PSP", "summary": "A payment service provider that participates in Faster Payments and provides relevant accounts, and is therefore bound by the regulator's reimbursement direction. This is a wider population than the scheme's membership: Schedule 4 applies whether or not the provider is a member of Faster Payments and party to the FPS Rules. Every such provider had to register with the operator and be onboarded to the claims management system, and each is answerable to Pay.UK for its own compliance.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "section 3, Application; clauses 2.2, 2.3, 2.4, 2.5 and 10.4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.psr-specific-direction-20-july-2024", "section": "paragraphs 1.5, 4.1, 8.1 and 10.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "FPS Reimbursement Rules Schedule 4 v3.0, the Application heading in section 3, clauses 2.2 to 2.5 and the definition in clause 10.4; PSR Specific Direction 20 (July 2024), paragraphs 1.5, 4.1, 8.1 and 10.1. Both read 2026-09-20.", "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).", "source_edition": "FPS Reimbursement Rules, Schedule 4, v3.0 dated 26 September 2024, read 2026-09-20, together with PSR Specific Direction 20 (July 2024) and the two PSR notices of value, all read the same day.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that Schedule 4 binds every provider offering relevant accounts whether or not a scheme member, and the registration and onboarding duties." }, { "source": "uk-fps:src.psr-specific-direction-20-july-2024", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the equal footing purpose, the registration deadline, and that the direction applies to all providers with relevant accounts." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:rule.directed-provider-population-is-wider-than-membership", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.operator-monitors-compliance-and-reports-to-the-regulator", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.providers-must-tell-consumers-and-change-their-terms", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.reimbursement-rules-bind-non-members", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:role.faster-payments-operator", "id": "role.faster-payments-operator", "rail": "uk-fps", "class": "Role", "name": "Pay.UK Limited, the Faster Payments Operator", "summary": "The company that writes the FPS Rules and operates the scheme. It outsources the central infrastructure to Vocalink, owns the Faster Payments trade mark and licenses participants to use it, sets the data standard participants must use, runs the Reimbursement Claims Management System and the reimbursement directory, monitors compliance with the reimbursement rules and reports on it to the regulator, and can instruct the Bank of England to draw on a participant's pre-funded account when that participant cannot settle. It also operates Bacs and the Image Clearing System.", "kind": "operator", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-pfmi-self-assessment-2025", "section": "2, 2.1, 2.2, 22.1 and 23.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "sections 1.4, 6 and 10.4", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "clauses 2.2, 2.3 and section 7", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Pay.UK 2025 PFMI self-assessment, sections 2, 2.1, 2.2, 22.1 and 23.1; Faster Payments System Principles v11, sections 1.4, 6 and 10.4; FPS Reimbursement Rules Schedule 4 v3.0, clauses 2.2 and 2.3 and section 7. All read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date the participation framework", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-pfmi-self-assessment-2025", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms Pay.UK as the FPS rule writer and scheme operator, outsourcing the central infrastructure to Vocalink and operating Bacs and the Image Clearing System." }, { "source": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms Pay.UK's role running the reimbursement directory and the RCMS, and its compliance monitoring duty under section 7." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:rule.dcsp-eligibility", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.designated-for-settlement-finality", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.iso-8583-not-iso-20022", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.net-sender-cap-set-by-each-participant", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.onboarding-takes-9-to-12-months", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.operator-monitors-compliance-and-reports-to-the-regulator", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.pre-funded-account-equal-to-net-sender-cap", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.rejection-and-return-code-lists-are-not-published", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.schedule-4-is-a-scheme-rule-the-regulator-enforces", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.who-participates-today", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:role.faster-payments-operator", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:role.faster-payments-operator", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:role.fca", "id": "role.fca", "rail": "uk-fps", "class": "Role", "name": "Financial Conduct Authority", "summary": "The conduct regulator of the payment service providers themselves, not of the scheme. Every directly connected participant must be an authorised provider under the Payment Services Regulations 2017, which the Authority administers, and a non-bank provider may need to engage with it before the Bank of England will consider settlement facilities. Two scheme obligations point at it by name: a sending participant must retry a standing order or forward dated payment later the same day where the payer had insufficient funds, which the System Principles attribute to the Authority's requirements, and Schedule 4 takes its meaning of a vulnerable consumer from the Authority's guidance.", "kind": "authority", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "sections 4.1, 5.2 and 5.3; section 10.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "clause 10.4, definition of Vulnerable Consumer", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, sections 4.1, 5.2, 5.3 and 10.3; FPS Reimbursement Rules Schedule 4 v3.0, clause 10.4. Both read 2026-09-20. The Authority's own guidance on the fair treatment of vulnerable customers, and the retry requirement Pay.UK attributes to the Authority, were not read [Unverified].", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date the participation framework", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the authorisation requirement under the Payment Services Regulations 2017 and the same day retry requirement Pay.UK attributes to the Authority." }, { "source": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that Schedule 4 takes its meaning of a vulnerable consumer from the Authority's guidance on fair treatment of vulnerable customers." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:role.indirect-agency", "id": "role.indirect-agency", "rail": "uk-fps", "class": "Role", "name": "Indirect Agency", "summary": "An institution that is not connected to the FPS central infrastructure and sends and receives Faster Payments through a directly connected participant, for itself or for its customers. The channel, interface and transaction limits it gets are its sponsor's commercial choice. Its sponsoring settling participant maintains its entries in the Extended Industry Sort Code Directory and answers payments on its behalf.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "section 4.3; Required Elements, Availability to Receive Payments, Delivery Channel, Limits, Redirections", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, section 4.3 and the indirect column of the Required Elements table, read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date the participation framework", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the indirect agency's access through a sponsor, the sponsor's commercial control of channel and limits, and the sponsor's EISCD maintenance duty." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:rule.cass-redirection-happens-inside-the-infrastructure", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.dcnsp-and-indirect-access", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.participants-set-their-own-lower-limits", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:role.psr", "id": "role.psr", "rail": "uk-fps", "class": "Role", "name": "Payment Systems Regulator", "summary": "The economic regulator of Faster Payments, because HM Treasury designated the system under the Financial Services (Banking Reform) Act 2013. It directs participants under section 54 of that Act and requires the operator to change its rules under section 55. Specific Direction 20 obliges providers to reimburse scam victims, Specific Requirement 1 made Pay.UK write Schedule 4, and Specific Direction 17 obliges named providers to offer Confirmation of Payee. It sets the reimbursement ceiling and the excess by notice and may change either at any time, and it, rather than Pay.UK, enforces Schedule 4.", "kind": "authority", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.psr-specific-direction-20-july-2024", "section": "paragraphs 2.1, 2.2, 2.4 and 10.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "clauses 2.1, 9.2.2, 9.2.5, 3.7 and 4.15i", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-pfmi-self-assessment-2025", "section": "2.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "PSR Specific Direction 20 (July 2024), paragraphs 2.1, 2.2, 2.4 and 10.1; FPS Reimbursement Rules Schedule 4 v3.0, clauses 2.1, 3.7, 4.15i, 9.2.2 and 9.2.5; Pay.UK 2025 PFMI self-assessment, section 2.1. All read 2026-09-20. Pay.UK's self-assessment records at its own footnote 3 that the government announced on 11 March 2025 that the regulator will be abolished and many of its functions absorbed into the Financial Conduct Authority, and that the framework was unchanged when the assessment was written. Whether that has happened at read time is [Unverified] here.", "confidence": "medium" }, "currency": { "effective_since": "2024-07-12", "effective_to": null, "effective_note": "Specific Direction 20 (July 2024) came into force on 12 July 2024 and revoked the version given on 19 December 2023 (paragraphs 11.1 and 12.1). Pay.UK records that the regulator is to be abolished and its functions moved to the Financial Conduct Authority; no commencement for that change was read here, so any record citing a regulator instrument should be read as naming the body that made it.", "source_edition": "PSR Specific Direction 20 (July 2024); FPS Reimbursement Rules Schedule 4 v3.0 (26 September 2024); Pay.UK 2025 PFMI self-assessment. All read 2026-09-20.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.psr-specific-direction-20-july-2024", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the regulator's designation, its powers to direct participants and require rule changes, and Specific Direction 20's reimbursement requirement." }, { "source": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that the regulator, not Pay.UK, enforces Schedule 4, and that it sets the reimbursement ceiling and excess by notice which it may change at any time." }, { "source": "uk-fps:src.payuk-pfmi-self-assessment-2025", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the regulator's designation under the Financial Services (Banking Reform) Act 2013 and the announced abolition and transfer of its functions to the Financial Conduct Authority." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:rule.operator-monitors-compliance-and-reports-to-the-regulator", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.schedule-4-is-a-scheme-rule-the-regulator-enforces", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:role.receiving-fps-institution", "id": "role.receiving-fps-institution", "rail": "uk-fps", "class": "Role", "name": "Receiving FPS Institution", "summary": "The participant that receives a payment from the FPS central infrastructure and answers it. For every payment it must respond within a few seconds with an unqualified acceptance, a qualified acceptance carrying a qualifier code, or a rejection carrying a rejection code, and it must be able to receive and answer payments at all hours without exception. Where it cannot make funds available it sends the money back as a fresh Return Payment quoting a return reason.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "Required Elements, Availability of Funds to the Beneficiary, Availability to Receive Payments, Returns", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-certainty-of-fate-rule-clarification-2026-01", "section": "annex, rules 6.2 and 10.1", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, Required Elements (Availability of Funds to the Beneficiary, Availability to Receive Payments, Error Checking, Returns); Certainty of Fate annex, rules 6.2 and 10.1. Both read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date the participation framework", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the receiving institution's duty to respond within seconds with one of three outcomes, to remain available at all hours, and to send a Return Payment where funds cannot be made available." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:exc.bank-error-recovery", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:exc.credit-payment-recovery", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:exc.rejection", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:exc.rejection", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:exc.return-payment", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:exc.return-payment", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.clearing-24-7", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.fraud-and-money-laundering-holds-are-each-providers-own", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.iso-8583-not-iso-20022", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.no-recall-and-no-cancellation-once-submitted", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.no-revocation-messaging", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.partial-return-needs-the-originators-agreement", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.payment-originating-overseas-carries-a-bic-in-tag-42", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.qualifier-codes-signal-five-timescales", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.receiving-institution-decides-in-seconds", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.reference-and-remittance-fields", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.rejection-and-return-code-lists-are-not-published", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.return-blocked-by-a-transaction-limit-must-be-agreed", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.return-payment-is-a-new-payment", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.return-payment-within-1-to-3-working-days", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.three-response-outcomes", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:role.receiving-fps-institution", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:role.receiving-fps-institution", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:rule.return-reason-required", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:role.receiving-psp", "id": "role.receiving-psp", "rail": "uk-fps", "class": "Role", "name": "Receiving PSP (reimbursement rules)", "summary": "Under the reimbursement rules, the provider of the relevant account a scam payment was received into. It may volunteer information about the claim within three business days, must answer an information request accurately, pays the sending provider its share of what the victim got back within five business days of being told the amount is due, and returns any money it recovers, keeping only what it had paid out. It owes nothing toward a voluntary reimbursement or toward anything the sending provider pays after closing the claim.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "clauses 3.5, 4.2, 4.7, 5.2, 5.7, 6.2, 6.3, 6.4 and 10.4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "FPS Reimbursement Rules Schedule 4 v3.0, clauses 3.5, 4.2, 4.7, 5.2, 5.7, 6.2 to 6.4 and the definition in clause 10.4, read 2026-09-20.", "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).", "source_edition": "FPS Reimbursement Rules, Schedule 4, v3.0 dated 26 September 2024, read 2026-09-20, together with PSR Specific Direction 20 (July 2024) and the two PSR notices of value, all read the same day.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the Receiving PSP's opportunity to respond, information request duty, contribution payment, repatriation and exemption from voluntary or post closure payments." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:rule.contribution-paid-within-five-business-days", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.receiving-provider-answers-an-information-request-by-the-25th-business-day", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.receiving-provider-chooses-what-to-volunteer-and-when-to-repatriate", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.receiving-provider-may-respond-within-three-business-days", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.reimbursable-contribution-is-half-apportioned", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.reimbursement-does-not-affect-finality", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.repatriation-apportionment", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.repatriation-within-three-business-days-of-concluding-investigations", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.statutory-liability-for-non-execution-or-late-execution", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.voluntary-reimbursement-is-outside-the-regime", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.wrong-unique-identifier-recovery-duty", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:role.sending-fps-institution", "id": "role.sending-fps-institution", "rail": "uk-fps", "class": "Role", "name": "Sending FPS Institution", "summary": "The participant that submits a payment to the FPS central infrastructure on its own or a customer's behalf. It must tell its customer the fate of the payment once the receiving institution has answered, and for an attended single immediate payment it must do so within 15 seconds. It decides its own level of error checking before submission, may hold a payment for fraud or money laundering investigation before it reaches the infrastructure, and is told when the infrastructure redirects one of its payments under the Current Account Switch Service.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "section 5.1; Required Elements, Fate of Payment, Error Checking (Sending Participant), Fraud, Redirections", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-certainty-of-fate-rule-clarification-2026-01", "section": "annex, rule 9.3.1", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, section 5.1 and the Required Elements table (Fate of Payment, Error Checking, Fraud, Redirections); Pay.UK's Certainty of Fate proposed rule clarification, annex rule 9.3.1. Both read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date the participation framework", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the sending institution's fate notification duty, error checking discretion, fraud hold option and redirection notification." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:exc.bank-error-recovery", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:exc.credit-payment-recovery", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:mandate.standing-order-instruction", "type": "given_to", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.attended-payer-told-fate-within-15-seconds", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.bank-error-recovery-for-payments-sent-in-bulk-by-mistake", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.cass-redirection-happens-inside-the-infrastructure", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.clearing-24-7", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.confirmation-of-payee-gives-the-payer-four-outcomes", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.credit-payment-recovery-is-not-a-reversal", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.fraud-and-money-laundering-holds-are-each-providers-own", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.irrevocable-on-submission-to-ci", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.iso-8583-not-iso-20022", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.near-real-time-guideline-10-and-15-seconds", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.no-recall-and-no-cancellation-once-submitted", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.no-revocation-messaging", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.partial-return-needs-the-originators-agreement", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.participants-set-their-own-lower-limits", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.payment-originating-overseas-carries-a-bic-in-tag-42", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.reference-and-remittance-fields", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.retry-later-the-same-day-on-insufficient-funds", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.return-blocked-by-a-transaction-limit-must-be-agreed", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.standing-orders-90-percent-before-06-00", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.standing-orders-weekdays-only", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.three-response-outcomes", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:role.sending-fps-institution", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:role.sending-fps-institution", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:role.sending-psp", "id": "role.sending-psp", "rail": "uk-fps", "class": "Role", "name": "Sending PSP (reimbursement rules)", "summary": "Under the reimbursement rules, the provider that holds the relevant account a scam payment was made from. It collects the claim, tells the receiving provider, waits for the chance to respond to pass, assesses whether the payments are reimbursable, decides on gross negligence and on vulnerability, may stop the clock for more information, pays the victim, tells the victim in writing, claims half back from the receiving provider, and keeps a record of each assessment. It is not the same thing as the Sending FPS Institution: a Sending PSP need not be a scheme member.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "clauses 3.1, 3.3, 3.12, 4.1, 4.3, 4.5, 4.9, 4.10, 4.11, 4.12, 5.1 and 10.4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "FPS Reimbursement Rules Schedule 4 v3.0, clauses 3.1, 3.3, 3.12, 4.1, 4.3, 4.5, 4.9 to 4.12, 5.1 and the definition in clause 10.4, read 2026-09-20.", "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).", "source_edition": "FPS Reimbursement Rules, Schedule 4, v3.0 dated 26 September 2024, read 2026-09-20, together with PSR Specific Direction 20 (July 2024) and the two PSR notices of value, all read the same day.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the Sending PSP's claim collection, notification, assessment, stop the clock, payment, notice, contribution claim and record keeping duties." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:exc.app-scam-claim", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.app-reimbursement-requirement", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.claim-decided-and-closed-by-the-35th-business-day", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.claim-excess-up-to-100", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.consumer-standard-of-caution-exception", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.execution-by-the-end-of-the-next-business-day", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.fraud-delay-to-the-fourth-business-day", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.maximum-level-of-reimbursement", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.no-excess-for-a-vulnerable-consumer", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.notify-the-receiving-provider-within-two-business-hours", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.other-grounds-a-claim-is-not-reimbursable", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.other-legal-regimes-are-not-displaced", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.outcome-must-be-told-to-the-consumer-in-writing", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.receiving-provider-answers-an-information-request-by-the-25th-business-day", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.receiving-provider-may-respond-within-three-business-days", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.reimbursable-contribution-is-half-apportioned", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.reimburse-within-five-business-days", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.reimbursement-does-not-affect-finality", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.reimbursement-overrides-the-wrong-identifier-defence", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.repatriation-apportionment", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.sending-provider-judges-the-scam-claim", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.statutory-liability-for-non-execution-or-late-execution", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.statutory-refund-for-an-unauthorised-transaction", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.stop-the-clock-grounds", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.thirteen-month-reporting-limit", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.uk-to-uk-scope-of-the-reimbursement-requirement", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.voluntary-reimbursement-is-outside-the-regime", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.wrong-unique-identifier-recovery-duty", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:role.sponsoring-dcsp", "id": "role.sponsoring-dcsp", "rail": "uk-fps", "class": "Role", "name": "Sponsoring settling participant", "summary": "A settling participant acting for another institution: authorising a non-settling participant's debits and credits in near real time and managing its Bank of England settlement, or carrying an indirect agency's payments and answering on its behalf. Under the reimbursement rules a sponsoring settling participant is not answerable for a provider it sponsors, unless it controls that provider's access to scam claim funds.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "sections 4.2 and 4.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "clause 2.5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, sections 4.2 and 4.3; FPS Reimbursement Rules Schedule 4 v3.0, clause 2.5. Both read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date the participation framework", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms a settling participant's sponsorship of a non-settling participant and of an indirect agency." }, { "source": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that a sponsoring settling participant is not answerable for a provider it sponsors unless it controls that provider's access to scam claim funds." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:rule.bank-error-recovery-for-payments-sent-in-bulk-by-mistake", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.dcnsp-and-indirect-access", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.dcnsp-settles-through-its-sponsor", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.reimbursement-rules-bind-non-members", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:rule.app-reimbursement-requirement", "id": "rule.app-reimbursement-requirement", "rail": "uk-fps", "class": "Rule", "name": "The sending provider must reimburse a scam victim in full", "statement": "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.", "rests_on": "rule", "facet": "liability", "parameters": { "liability_holder": { "role": "uk-fps:role.sending-psp", "condition": "the payments are reimbursable FPS APP scam payments and the claim was reported within 13 months of the last of them", "text": "the provider holding the account the money was paid from reimburses the victim in full, up to the ceiling and less any excess, and then recovers half from the receiving providers" } }, "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "clauses 3.1, 3.2, 3.10, 3.11 and 10.4 (APP scam)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.psr-specific-direction-20-july-2024", "section": "paragraphs 3.1, 3.2 and 4.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "uk-fps:exc.app-scam-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "FPS Reimbursement Rules Schedule 4 v3.0, clauses 3.1, 3.2, 3.10 and 3.11 and the definitions in clause 10.4; PSR Specific Direction 20 (July 2024), paragraphs 3.1, 3.2 and 4.1. Both read 2026-09-20.", "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).", "source_edition": "FPS Reimbursement Rules, Schedule 4, v3.0 dated 26 September 2024, read 2026-09-20, together with PSR Specific Direction 20 (July 2024) and the two PSR notices of value, all read the same day.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the reimbursement requirement, that it binds directed providers whether or not scheme members, the 7 October 2024 start date, and the definition of an APP scam payment including that a victim party to the fraud is excluded." }, { "source": "uk-fps:src.psr-specific-direction-20-july-2024", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the reimbursement requirement in paragraph 3.1, the 7 October 2024 implementation date in paragraph 3.2, and that from that date all directed providers must comply in paragraph 4.1." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.liability-australia-has-no-mandatory-scam-reimbursement-rule", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:rule.attended-payer-told-fate-within-15-seconds", "id": "rule.attended-payer-told-fate-within-15-seconds", "rail": "uk-fps", "class": "Rule", "name": "An attending payer must be told the fate of the payment within 15 seconds", "statement": "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.", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "section 5.1; Required Elements, Fate of Payment", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "uk-fps:txn.single-immediate-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, section 5.1 and the Fate of Payment row of the Required Elements table, read 2026-09-20. The window is not carried as a typed parameter: Orca Core v0's time_window has no unit below an hour, so the figure stays in this statement.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the 15 second window for advising an attending payer of a single immediate payment's fate, unchanged where one or two non-settling participants are in the chain." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.bank-error-recovery-for-payments-sent-in-bulk-by-mistake", "id": "rule.bank-error-recovery-for-payments-sent-in-bulk-by-mistake", "rail": "uk-fps", "class": "Rule", "name": "Bank Error Recovery covers a participant's own bulk mistake", "statement": "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.", "rests_on": "guidance", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "Required Elements, Bank Error Recover", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sponsoring-dcsp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "uk-fps:exc.bank-error-recovery", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, the Bank Error Recover row of the Required Elements table, read 2026-09-20.", "confidence": "low" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "primary_not_public": true, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.cass-redirection-happens-inside-the-infrastructure", "id": "rule.cass-redirection-happens-inside-the-infrastructure", "rail": "uk-fps", "class": "Rule", "name": "The infrastructure silently redirects a switched account, and nobody decides", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "Required Elements, Redirections", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.central-infrastructure-provider", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.indirect-agency", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, the Redirections row of the Required Elements table, read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that the central infrastructure checks every payment against the switch service redirection table and automatically redirects, notifying the sending participant afterwards." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.claim-decided-and-closed-by-the-35th-business-day", "id": "rule.claim-decided-and-closed-by-the-35th-business-day", "rail": "uk-fps", "class": "Rule", "name": "Whatever happens, the claim is decided and closed by the 35th business day", "statement": "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.", "rests_on": "rule", "facet": "liability", "parameters": { "time_window": { "count": 35, "unit": "business_day", "from": "receipt", "text": "before the end of the 35th business day after the claim was reported" } }, "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "clauses 4.9, 4.13 and 10.4 (Claim closed)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "uk-fps:exc.app-scam-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "FPS Reimbursement Rules Schedule 4 v3.0, clauses 4.9 and 4.13 and the definition of Claim closed in clause 10.4, read 2026-09-20.", "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).", "source_edition": "FPS Reimbursement Rules, Schedule 4, v3.0 dated 26 September 2024, read 2026-09-20, together with PSR Specific Direction 20 (July 2024) and the two PSR notices of value, all read the same day.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the 35th business day longstop for deciding and closing a claim, and that a claim may only be closed once assessed and the opportunity to respond has ended, either by reimbursing the victim or rejecting the claim." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.claim-excess-up-to-100", "id": "rule.claim-excess-up-to-100", "rail": "uk-fps", "class": "Rule", "name": "A provider may deduct an excess of up to GBP 100, once per claim", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.psr-sr1-notice-maximum-excess-value-2023-12", "section": "paragraphs 1.1 to 1.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "clauses 4.15 and 4.15i and clause 4.4", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "uk-fps:exc.app-scam-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "PSR Specific Requirement 1, notice of maximum excess value (made 19 December 2023, in force 7 October 2024), paragraphs 1.1 to 1.3; FPS Reimbursement Rules Schedule 4 v3.0, clauses 4.4, 4.15 and 4.15i. Both read 2026-09-20. The figure is not carried as a typed limit for the same reason as the ceiling: it is per claim, which the limit parameter cannot say.", "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).", "source_edition": "FPS Reimbursement Rules, Schedule 4, v3.0 dated 26 September 2024, read 2026-09-20, together with PSR Specific Direction 20 (July 2024) and the two PSR notices of value, all read the same day.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.psr-sr1-notice-maximum-excess-value-2023-12", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the maximum excess of 100 pounds per claim, that a sending provider may apply the maximum, a lower figure or none, and that the figure does not move with inflation or any other measure." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.clearing-24-7", "id": "rule.clearing-24-7", "rail": "uk-fps", "class": "Rule", "name": "Clearing runs at every hour of every day", "statement": "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.", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "sections 3 and 5.1; Required Elements, Availability to Receive Payments", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-overview-page", "section": "opening description", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.receiving-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, sections 3 and 5.1 and the Availability to Receive Payments row of the Required Elements table; Pay.UK's Faster Payment System page. Both read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms clearing at every hour of every day including weekends and bank holidays since the rail's launch in 2008, and the duty to remain available to receive payments with stand-in processing during an incident or planned maintenance." }, { "source": "uk-fps:src.payuk-fps-overview-page", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the system is available day and night, 365 days a year, since its creation in 2008." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.confirmation-of-payee-gives-the-payer-four-outcomes", "id": "rule.confirmation-of-payee-gives-the-payer-four-outcomes", "rail": "uk-fps", "class": "Rule", "name": "Confirmation of Payee hands the decision to the payer, in four outcomes", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-confirmation-of-payee-faqs", "section": "the whole page", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "section 10.3; Required Elements, Error Checking (Sending Participant)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.psr-specific-direction-17-consolidated-july-2026", "section": "paragraphs 1.7, 3 and 7.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.consumer", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Pay.UK's Confirmation of Payee FAQs; Faster Payments System Principles v11, section 10.3 and the Error Checking (Sending Participant) row; PSR Specific Direction 17 as consolidated in July 2026, paragraphs 1.7, 3 and 7.2. All read 2026-09-20. The October 2022 direction itself was not read, and the July 2026 text is a consultation draft showing proposed changes, so what binds today is [Unverified].", "confidence": "medium" }, "currency": { "effective_since": "2026-09-20", "effective_to": null, "effective_note": "Pay.UK's Confirmation of Payee FAQ page carries no date; the date here is the day it was read. The consolidated Specific Direction 17 text read alongside it says at paragraphs 1.7 and 7.2 that the direction ceases to be in force on 1 November 2026 unless the regulator varies, revokes or extends it, and shows a proposal to remove that expiry and add a third group of providers bound after 31 December 2026. Whether that proposal has been made is [Unverified].", "source_edition": "Pay.UK's Confirmation of Payee FAQs as read 2026-09-20; PSR Specific Direction 17, consolidated text published July 2026 alongside consultation CP26/2.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-confirmation-of-payee-faqs", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the four outcomes match, close match, no match and unavailable with its three causes, that Pay.UK owns the rules as the payment systems operator, the no guarantee of reimbursement statement, the more than 140 offering organisations, the payments agnostic scope across Faster Payments, CHAPS and Bacs, and that existing payees and standing orders may not be checked." }, { "source": "uk-fps:src.psr-specific-direction-17-consolidated-july-2026", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the direction obliges a directed provider to have and use a Confirmation of Payee system, and that it ceases to be in force on 1 November 2026 unless the regulator varies, revokes or extends it." }, { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that Confirmation of Payee may be promoted to sending customers as an improved way of checking payment details before submission." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.consumer-standard-of-caution-exception", "id": "rule.consumer-standard-of-caution-exception", "rail": "uk-fps", "class": "Rule", "name": "Gross negligence against four standards can cost the consumer the right", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "clauses 3.6, 3.11(1) and 10.4 (Competent National Authority, Consumer Standard of Caution Exception)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.consumer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "uk-fps:exc.app-scam-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "FPS Reimbursement Rules Schedule 4 v3.0, clauses 3.6 and 3.11 and the definitions in clause 10.4, read 2026-09-20. The regulator's own Consumer Standard of Caution Exception publication, which Schedule 4 points at and which the regulator may amend, was not read [Unverified].", "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).", "source_edition": "FPS Reimbursement Rules, Schedule 4, v3.0 dated 26 September 2024, read 2026-09-20, together with PSR Specific Direction 20 (July 2024) and the two PSR notices of value, all read the same day.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the four standards of caution, that the bar is gross negligence, that the exception falls away for a vulnerable consumer materially affected, and the definition of a competent national authority." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.contribution-paid-within-five-business-days", "id": "rule.contribution-paid-within-five-business-days", "rail": "uk-fps", "class": "Rule", "name": "The contribution is paid within five business days of being asked", "statement": "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.", "rests_on": "rule", "facet": "liability", "parameters": { "time_window": { "count": 5, "unit": "business_day", "from": "notice_of_refusal", "text": "five business days from the sending provider's notification that the contribution is payable" } }, "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "clauses 3.5, 5.7, 5.8 and 5.9", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.receiving-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "uk-fps:exc.app-scam-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "FPS Reimbursement Rules Schedule 4 v3.0, clauses 3.5 and 5.7 to 5.9, read 2026-09-20.", "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).", "source_edition": "FPS Reimbursement Rules, Schedule 4, v3.0 dated 26 September 2024, read 2026-09-20, together with PSR Specific Direction 20 (July 2024) and the two PSR notices of value, all read the same day.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the receiving provider's five business day window from the sending provider's notification, payment over Faster Payments, and the two grounds on which a contribution request may not be submitted." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.credit-payment-recovery-is-not-a-reversal", "id": "rule.credit-payment-recovery-is-not-a-reversal", "rail": "uk-fps", "class": "Rule", "name": "Credit Payment Recovery is an attempt, not a right", "statement": "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.", "rests_on": "guidance", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "Required Elements, Credit Payment Recovery", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "uk-fps:exc.credit-payment-recovery", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, the Credit Payment Recovery row of the Required Elements table, read 2026-09-20. That the receiving institution is under no duty to return the funds is an absence in the documents read, not a statement in them [Inference].", "confidence": "low" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "primary_not_public": true, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.return-a-return-is-a-new-payment-going-the-other-way", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:rule.dcnsp-and-indirect-access", "id": "rule.dcnsp-and-indirect-access", "rail": "uk-fps", "class": "Rule", "name": "Two ways in that do not need a Bank of England account", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "sections 4.2 and 4.3; Required Elements, Availability to Receive Payments, Delivery Channel, Limits", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.dcnsp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.indirect-agency", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sponsoring-dcsp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, sections 4.2 and 4.3 and the indirect column of the Required Elements table, read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the DCNSP sponsorship arrangement and its exemption from the Bank of England settlement facilities requirement, and that an indirect agency connects through a sponsor whose commercial choices govern its channel, interface and limits." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.dcnsp-settles-through-its-sponsor", "id": "rule.dcnsp-settles-through-its-sponsor", "rail": "uk-fps", "class": "Rule", "name": "A non-settling participant settles through its sponsor's account", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "section 4.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-pfmi-self-assessment-2025", "section": "2.2.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sponsoring-dcsp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.dcnsp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, section 4.2; Pay.UK 2025 PFMI self-assessment, section 2.2.2. Both read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that the sponsoring settling participant gives real time authorisation on the non-settling participant's debits and credits and manages its Bank of England settlement." }, { "source": "uk-fps:src.payuk-pfmi-self-assessment-2025", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that a non-settling participant uses its sponsoring settling participant's settlement account in RTGS." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.dcsp-eligibility", "id": "rule.dcsp-eligibility", "rail": "uk-fps", "class": "Rule", "name": "What it takes to connect directly and settle", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "sections 4, 4.1 and 12", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.dcsp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.faster-payments-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, section 4, section 4.1 and section 12, read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the requirements to become a directly connected settling participant, that there is no fee to join the scheme itself but a direct participant commits to the infrastructure provider's charges, and the note on additional Financial Conduct Authority engagement for a non-bank provider." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.deferred-net-settlement-three-times-each-working-day", "id": "rule.deferred-net-settlement-three-times-each-working-day", "rail": "uk-fps", "class": "Rule", "name": "Settlement runs three times each working day", "statement": "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.", "rests_on": "rule", "facet": "settlement", "parameters": { "time_window": { "times": [ "07:00", "13:00", "17:00" ], "timezone": "Europe/London", "on": "business_day", "text": "three settlement cycles on each working day, at 07:00, 13:00 and 17:00" } }, "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-pfmi-self-assessment-2025", "section": "2.2 and 2.2.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "section 6", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.dcsp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.bank-of-england", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.central-infrastructure-provider", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Pay.UK 2025 PFMI self-assessment, sections 2.2 and 2.2.2; Faster Payments System Principles v11, section 6. Both read 2026-09-20. The times are read as United Kingdom local time, which neither document states in terms [Inference].", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-pfmi-self-assessment-2025", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms net settlement over RTGS three times each working day at 07:00, 13:00 and 17:00, separate from real time clearing." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.designated-for-settlement-finality", "id": "rule.designated-for-settlement-finality", "rail": "uk-fps", "class": "Rule", "name": "Faster Payments is designated for settlement finality", "statement": "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.", "rests_on": "law", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-pfmi-self-assessment-2025", "section": "2.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.faster-payments-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.bank-of-england", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Pay.UK 2025 PFMI self-assessment, section 2.1, read 2026-09-20. The Regulations and the Banking Act themselves were not read; this record rests on Pay.UK's statement of them [Unverified].", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-pfmi-self-assessment-2025", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms designation for settlement finality under the Financial Markets and Insolvency (Settlement Finality) Regulations 1999 and recognition under section 184 of the Banking Act 2009." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.directed-provider-population-is-wider-than-membership", "id": "rule.directed-provider-population-is-wider-than-membership", "rail": "uk-fps", "class": "Rule", "name": "Being bound is not the same as being a member", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "section 3 Application; clause 10.4 (Member of Faster Payments, Directed PSP, Indirect Access Provider)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.psr-specific-direction-20-july-2024", "section": "paragraphs 1.5, 7.1, 7.3 and 10.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.directed-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "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, 7.3 and 10.1. Both read 2026-09-20.", "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).", "source_edition": "FPS Reimbursement Rules, Schedule 4, v3.0 dated 26 September 2024, read 2026-09-20, together with PSR Specific Direction 20 (July 2024) and the two PSR notices of value, all read the same day.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the definitions of Member of Faster Payments and Directed PSP in clause 10.4 and the Application section stating Schedule 4 applies whether or not a provider is a scheme member." }, { "source": "uk-fps:src.psr-specific-direction-20-july-2024", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the equal footing purpose in paragraph 1.5, the indirect access provider annual and monthly reporting duties in paragraphs 7.1 and 7.3, and the direction's application to all providers with relevant accounts in paragraph 10.1." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.execution-by-the-end-of-the-next-business-day", "id": "rule.execution-by-the-end-of-the-next-business-day", "rail": "uk-fps", "class": "Rule", "name": "The money must reach the payee's provider by the end of the next business day", "statement": "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.", "rests_on": "law", "facet": "consumer-law", "parameters": { "time_window": { "count": 1, "unit": "business_day", "from": "receipt", "text": "by the end of the business day following the time of receipt of the payment order" } }, "relations": [ { "type": "sourced_from", "to": "uk-fps:src.psrs-2017-part-7", "section": "regulation 86(1) and 86(2)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The Payment Services Regulations 2017, regulation 86(1) and (2), read on legislation.gov.uk 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "Unknown: the consolidated text read does not state when this regulation commenced", "effective_to": null, "effective_note": "The words inserted in regulation 86(1) to make room for the fraud delay were inserted on 30 October 2024 by SI 2024/1013; the consolidated text carries no commencement note for the original paragraph.", "source_edition": "The Payment Services Regulations 2017 (SI 2017/752), Part 7, current consolidated text on legislation.gov.uk read 2026-09-20.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.psrs-2017-part-7", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms regulation 86(1) and (2), the end of the next business day deadline, and the second business day extension for a paper payment order." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.fraud-and-money-laundering-holds-are-each-providers-own", "id": "rule.fraud-and-money-laundering-holds-are-each-providers-own", "rail": "uk-fps", "class": "Rule", "name": "Fraud and money laundering holds are the provider's own judgement", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "section 5.1; Required Elements, Fraud, Error Checking (Sending Participant)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.receiving-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, section 5.1 and the Fraud and Error Checking (Sending Participant) rows of the Required Elements table, read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that FPS does not mandate fraud checking, that each side applies its own policy and follows anti money laundering and know your customer law, and that a small percentage of attended payments may be held or rejected before submission." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.fraud-delay-to-the-fourth-business-day", "id": "rule.fraud-delay-to-the-fourth-business-day", "rail": "uk-fps", "class": "Rule", "name": "A provider may hold a payment to the fourth business day on suspicion of third party fraud", "statement": "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.", "rests_on": "law", "facet": "consumer-law", "parameters": { "time_window": { "count": 4, "unit": "business_day", "from": "receipt", "text": "the delay must end by no later than the end of the fourth business day following receipt of the payment order" } }, "relations": [ { "type": "sourced_from", "to": "uk-fps:src.psrs-2017-part-7", "section": "regulation 86(2A) to 86(2D)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The Payment Services Regulations 2017, regulation 86(2A) to (2D), read on legislation.gov.uk 2026-09-20, with the textual amendment note recording that the paragraphs were inserted on 30 October 2024 by the Payment Services (Amendment) Regulations 2024, SI 2024/1013.", "confidence": "high" }, "currency": { "effective_since": "2024-10-30", "effective_to": null, "effective_note": "Regulation 86(2A) to (2D) was inserted on 30 October 2024 by SI 2024/1013, as the textual amendment note F28 on legislation.gov.uk records.", "source_edition": "The Payment Services Regulations 2017 (SI 2017/752), Part 7, current consolidated text on legislation.gov.uk read 2026-09-20.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.psrs-2017-part-7", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms regulation 86(2A) to (2D), the fourth business day longstop, the notification duty and its timing, and the textual amendment note dating the insertion to 30 October 2024." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.irrevocable-on-submission-to-ci", "id": "rule.irrevocable-on-submission-to-ci", "rail": "uk-fps", "class": "Rule", "name": "A payment is irrevocable the moment it reaches the central infrastructure", "statement": "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.", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-pfmi-self-assessment-2025", "section": "key consideration 8.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "Required Elements, Revocability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "uk-fps:txn.single-immediate-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "uk-fps:txn.standing-order-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "uk-fps:txn.forward-dated-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "uk-fps:txn.direct-corporate-access", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Pay.UK 2025 PFMI self-assessment, key consideration 8.1; Faster Payments System Principles v11, the Revocability row of the Required Elements table. Both read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-pfmi-self-assessment-2025", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that the point of irrevocability of an individual FPS payment is the moment it is submitted to the central infrastructure, and that acceptance and settlement come after that point." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.iso-8583-not-iso-20022", "id": "rule.iso-8583-not-iso-20022", "rail": "uk-fps", "class": "Rule", "name": "Faster Payments runs on ISO 8583, not ISO 20022", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-pfmi-self-assessment-2025", "section": "key consideration 22.1", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "Required Elements, Account Statement, Payment Information, Error Checking (Receiving Participant); section 10.2", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.faster-payments-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.receiving-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Pay.UK 2025 PFMI self-assessment, key consideration 22.1; Faster Payments System Principles v11, the Account Statement, Payment Information and Error Checking rows of the Required Elements table and section 10.2. Both read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.maximum-level-of-reimbursement", "id": "rule.maximum-level-of-reimbursement", "rail": "uk-fps", "class": "Rule", "name": "Nothing above GBP 85,000 per claim has to be reimbursed", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.psr-sr1-notice-maximum-reimbursement-level-2024-09", "section": "paragraphs 1.1 to 1.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "clauses 3.7, 4.4 and 4.15ii", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "uk-fps:exc.app-scam-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:rule.voluntary-reimbursement-is-outside-the-regime", "note": "The closing sentence of this record, that anything paid above the ceiling is voluntary and the receiving provider owes nothing toward it, is that record restricted to the above-the-ceiling case. That record states it in general, for a late claim, a pre-7 October 2024 payment and a closed claim as well, and rests on Schedule 4 where this record's figure rests on the regulator's notice of value.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "PSR Specific Requirement 1, notice of maximum level of reimbursement value (made 25 September 2024, in force 7 October 2024), paragraphs 1.1 to 1.3; FPS Reimbursement Rules Schedule 4 v3.0, clauses 3.7, 4.4 and 4.15ii. Both read 2026-09-20. The GBP 85,000 figure is not carried as a typed limit: Orca Core v0's limit parameter can say per entry, batch, file or day, and this ceiling is per claim and across linked claims, which none of those says.", "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).", "source_edition": "FPS Reimbursement Rules, Schedule 4, v3.0 dated 26 September 2024, read 2026-09-20, together with PSR Specific Direction 20 (July 2024) and the two PSR notices of value, all read the same day.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.psr-sr1-notice-maximum-reimbursement-level-2024-09", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the maximum level of reimbursement of 85,000 pounds per claim, that it does not move with inflation or any other metric, that the regulator keeps it under review, and that it stays in force until varied or revoked." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:rule.voluntary-reimbursement-is-outside-the-regime", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:rule.near-real-time-guideline-10-and-15-seconds", "id": "rule.near-real-time-guideline-10-and-15-seconds", "rail": "uk-fps", "class": "Rule", "name": "Near real time means 10 seconds for 95 in 100 payments and 15 for the rest", "statement": "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.", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-certainty-of-fate-rule-clarification-2026-01", "section": "annex, rule 9.3.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "uk-fps:txn.single-immediate-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Pay.UK's Certainty of Fate proposed rule clarification v1.0, annex rule 9.3.1, read 2026-09-20. The annex prints the existing rule with the January 2026 proposals marked in bold; the two figures are in the existing wording, not in the proposal. The controlling FPS Rules were not read.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-certainty-of-fate-rule-clarification-2026-01", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the existing rule text defining near real time as within 10 seconds for 95 percent of payments and 15 seconds for the remaining 5 percent, and that achieving the timescale must not impair the accuracy or availability of customer information." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.net-sender-cap-set-by-each-participant", "id": "rule.net-sender-cap-set-by-each-participant", "rail": "uk-fps", "class": "Rule", "name": "Each settling participant sets its own net sender cap", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "section 6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-pfmi-self-assessment-2025", "section": "2.2.2", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.dcsp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.faster-payments-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, section 6; Pay.UK 2025 PFMI self-assessment, section 2.2.2. Both read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that each settling participant sets its own net sender cap to more than cover its anticipated maximum intra cycle debit position, and that Pay.UK reduces a participant's cap before drawing on its pre funding." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.net-settlement-final-at-rtgs-timestamp", "id": "rule.net-settlement-final-at-rtgs-timestamp", "rail": "uk-fps", "class": "Rule", "name": "Net settlement is final when the single amount carries the real time gross settlement timestamp", "statement": "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.", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-pfmi-self-assessment-2025", "section": "key consideration 8.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.bank-of-england", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.dcsp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Pay.UK 2025 PFMI self-assessment, key consideration 8.1, read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-pfmi-self-assessment-2025", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that net settlement finality for FPS occurs when the single settlement amount is recorded with the RTGS timestamp, distinct from the earlier point of irrevocability of an individual payment." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.no-excess-for-a-vulnerable-consumer", "id": "rule.no-excess-for-a-vulnerable-consumer", "rail": "uk-fps", "class": "Rule", "name": "No excess may be taken from a vulnerable consumer, though the ceiling still applies", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "clauses 3.7, 4.15iii and 10.4 (Vulnerable Consumer)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "uk-fps:exc.app-scam-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "FPS Reimbursement Rules Schedule 4 v3.0, clauses 3.7 and 4.15iii and the definition of Vulnerable Consumer in clause 10.4, read 2026-09-20. The Financial Conduct Authority guidance itself was not read [Unverified].", "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).", "source_edition": "FPS Reimbursement Rules, Schedule 4, v3.0 dated 26 September 2024, read 2026-09-20, together with PSR Specific Direction 20 (July 2024) and the two PSR notices of value, all read the same day.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that no excess may be applied where the victim was a vulnerable consumer materially affected, that the ceiling still applies regardless of vulnerability, and the definition of vulnerable consumer as the Financial Conduct Authority uses it." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.no-recall-and-no-cancellation-once-submitted", "id": "rule.no-recall-and-no-cancellation-once-submitted", "rail": "uk-fps", "class": "Rule", "name": "There is no recall on Faster Payments", "statement": "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.", "rests_on": "rule", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "Required Elements, Revocability; sections 5.2 and 5.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-pfmi-self-assessment-2025", "section": "key consideration 8.1", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.receiving-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:rule.no-revocation-messaging", "note": "The same absence stated as a fact about the system rather than about rights. That record rests on Pay.UK's PFMI self-assessment for the absence of any revocation messaging capability; this one rests on the System Principles for the absence of a scheme right, with the standing order and forward dated carve-out. A rail can lack the right and still carry the message, so the two claims are not one.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, the Revocability row 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.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that a payment cannot be revoked or recalled once sent to the central infrastructure, and that a sending participant may cancel a standing order or forward dated payment on customer request before it is sent, which the guide marks as competitive rather than a scheme right." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:rule.recall-there-is-no-recall-and-no-cancellation-message", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.no-revocation-messaging", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:rule.no-revocation-messaging", "id": "rule.no-revocation-messaging", "rail": "uk-fps", "class": "Rule", "name": "The system has no message for taking a payment back", "statement": "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.", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-pfmi-self-assessment-2025", "section": "key consideration 8.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "Required Elements, Revocability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.receiving-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:rule.no-recall-and-no-cancellation-once-submitted", "note": "The same absence stated as a rights rule rather than as a fact about the system. That record rests on the System Principles for the absence of a scheme right and carries the standing order and forward dated carve-out; this one rests on Pay.UK's PFMI self-assessment for the absence of any revocation messaging capability. A rail can lack the right and still carry the message, so the two claims are not one.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Pay.UK 2025 PFMI self-assessment, key consideration 8.1; Faster Payments System Principles v11, the Revocability row of the Required Elements table. Both read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-pfmi-self-assessment-2025", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that after submission no FPS payment can be reversed and that the system has no revocation messaging capability." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:rule.no-recall-and-no-cancellation-once-submitted", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:rule.notify-the-receiving-provider-within-two-business-hours", "id": "rule.notify-the-receiving-provider-within-two-business-hours", "rail": "uk-fps", "class": "Rule", "name": "The receiving provider must be told within two business hours", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "clauses 4.1 and 10.4 (Business hours)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "uk-fps:exc.app-scam-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "FPS Reimbursement Rules Schedule 4 v3.0, clause 4.1 and the definition of Business hours in clause 10.4, read 2026-09-20. The window is deliberately left untyped: Orca Core v0's time_window has an hour unit but no business hour, and two plain hours would say something the rule does not. The qualifier is carried in this statement instead.", "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).", "source_edition": "FPS Reimbursement Rules, Schedule 4, v3.0 dated 26 September 2024, read 2026-09-20, together with PSR Specific Direction 20 (July 2024) and the two PSR notices of value, all read the same day.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the two business hour notification window, the definition of business hour as nine to five on a business day, and the five items of information the notification must carry." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.onboarding-takes-9-to-12-months", "id": "rule.onboarding-takes-9-to-12-months", "rail": "uk-fps", "class": "Rule", "name": "Direct onboarding runs nine to twelve months", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "sections 2 and 11", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.faster-payments-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.dcsp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, sections 2 and 11, read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the nine to twelve month onboarding estimate, the seven named phases, that some may run in parallel, and the specific steps of the non-disclosure agreement, the letter of intent decision, certification testing, funding and defunding the Bank of England accounts, and the go or no go checkpoint." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.operator-monitors-compliance-and-reports-to-the-regulator", "id": "rule.operator-monitors-compliance-and-reports-to-the-regulator", "rail": "uk-fps", "class": "Rule", "name": "Pay.UK monitors compliance and reports it to the regulator", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "section 7 and clauses 11.1 to 11.4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.psr-specific-direction-20-july-2024", "section": "paragraphs 8.4 to 8.7 and 9.1 to 9.9", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.faster-payments-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.directed-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.psr", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "FPS Reimbursement Rules Schedule 4 v3.0, section 7 and clauses 11.1 to 11.4; PSR Specific Direction 20 (July 2024), paragraphs 8.4 to 8.7 and 9.1 to 9.9. Both read 2026-09-20. Specific Direction 19, the Compliance Monitoring Regime and the Compliance Data Reporting Standards, each named in those texts, were not read [Unverified].", "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).", "source_edition": "FPS Reimbursement Rules, Schedule 4, v3.0 dated 26 September 2024, read 2026-09-20, together with PSR Specific Direction 20 (July 2024) and the two PSR notices of value, all read the same day.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the five compliance monitoring responsibilities the regulator gives the operator in section 7, the compliance dashboard, and the permitted use and disclosure restrictions on compliance information in clauses 11.1 to 11.4." }, { "source": "uk-fps:src.psr-specific-direction-20-july-2024", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the five year retention duty, the accuracy and security obligations, the reasonable and proportionate information request standard in paragraphs 8.4 to 8.7, and the monthly reporting cycle including the nil return duty in paragraphs 9.1 to 9.9." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.other-grounds-a-claim-is-not-reimbursable", "id": "rule.other-grounds-a-claim-is-not-reimbursable", "rail": "uk-fps", "class": "Rule", "name": "Five further tests a claim has to pass", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "clauses 3.11(2) to 3.11(6) and 10.4 (Private civil dispute)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "uk-fps:exc.app-scam-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "FPS Reimbursement Rules Schedule 4 v3.0, clause 3.11 and the definition of Private civil dispute in clause 10.4, read 2026-09-20.", "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).", "source_edition": "FPS Reimbursement Rules, Schedule 4, v3.0 dated 26 September 2024, read 2026-09-20, together with PSR Specific Direction 20 (July 2024) and the two PSR notices of value, all read the same day.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the five further tests a claim must pass, the definition of a private civil dispute, and the 13 month and 7 October 2024 reporting conditions." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.other-legal-regimes-are-not-displaced", "id": "rule.other-legal-regimes-are-not-displaced", "rail": "uk-fps", "class": "Rule", "name": "The Ombudsman and the industry code sit alongside, not under, the scheme rule", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "clauses 2.6 and 5.2(b)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.consumer", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "FPS Reimbursement Rules Schedule 4 v3.0, clauses 2.6 and 5.2, read 2026-09-20. Neither the Ombudsman scheme rules nor the Contingent Reimbursement Model Code was read [Unverified].", "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).", "source_edition": "FPS Reimbursement Rules, Schedule 4, v3.0 dated 26 September 2024, read 2026-09-20, together with PSR Specific Direction 20 (July 2024) and the two PSR notices of value, all read the same day.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms clause 2.6, that handling a scam claim does not alter other legal obligations under regimes such as the Financial Ombudsman or the Contingent Reimbursement Model Code, and clause 5.2's treatment of a post closure payment as voluntary." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.outcome-must-be-told-to-the-consumer-in-writing", "id": "rule.outcome-must-be-told-to-the-consumer-in-writing", "rail": "uk-fps", "class": "Rule", "name": "The consumer is told the outcome in writing either way", "statement": "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.", "rests_on": "rule", "facet": "liability", "parameters": { "time_window": { "count": 1, "unit": "business_day", "from": "determination", "text": "the receiving provider is notified within one business day of the consumer being told in writing" } }, "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "clauses 4.4, 4.11 and 4.12", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "uk-fps:exc.app-scam-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "FPS Reimbursement Rules Schedule 4 v3.0, clauses 4.4, 4.11 and 4.12, read 2026-09-20.", "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).", "source_edition": "FPS Reimbursement Rules, Schedule 4, v3.0 dated 26 September 2024, read 2026-09-20, together with PSR Specific Direction 20 (July 2024) and the two PSR notices of value, all read the same day.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the written notice duty on a positive and a negative decision, the one business day window to notify the receiving provider, and the rule that additional payments from the same scam are raised as a new linked claim with no new excess." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.partial-return-needs-the-originators-agreement", "id": "rule.partial-return-needs-the-originators-agreement", "rail": "uk-fps", "class": "Rule", "name": "A partial return is a new payment and needs the originator's agreement", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-certainty-of-fate-rule-clarification-2026-01", "section": "annex, rule 10.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.receiving-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "uk-fps:exc.return-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps-return:rule.return-is-a-new-payment", "note": "The wider rule. That record states the whole of the Return Payment mechanic, the duty to agree a route when transaction limits stop the full amount going back in one payment, and the New Payment route this record covers on its own.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Pay.UK's Certainty of Fate proposed rule clarification v1.0, annex rule 10.1, read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-certainty-of-fate-rule-clarification-2026-01", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that a New Payment used instead of a Return Payment needs the agreement of the original payment's initiator and must quote the first 18 characters of the original payment identifier." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.participants-set-their-own-lower-limits", "id": "rule.participants-set-their-own-lower-limits", "rail": "uk-fps", "class": "Rule", "name": "A participant may set a lower limit, and most do", "statement": "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.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-transaction-limits-page", "section": "opening paragraphs and the per organisation tables", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "Required Elements, Limits (Individual Payment Amount)", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.indirect-agency", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Pay.UK's Faster Payment System transaction limits page and Faster Payments System Principles v11, the Limits row of the Required Elements table, both read 2026-09-20. That no rule bars a receiving participant from setting a lower limit is an absence in the documents read, not a statement in them [Inference].", "confidence": "medium" }, "currency": { "effective_since": "2026-09-20", "effective_to": null, "effective_note": "Pay.UK's transaction limits page carries no date and the per participant figures are the participants' own commercial settings, which move without notice. The date here is the day the page was read, not a date the rule took effect.", "source_edition": "Pay.UK's Faster Payment System transaction limits page as read 2026-09-20; Faster Payments System Principles v11.", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.payment-originating-overseas-carries-a-bic-in-tag-42", "id": "rule.payment-originating-overseas-carries-a-bic-in-tag-42", "rail": "uk-fps", "class": "Rule", "name": "A payment drawn on an overseas account is marked only by a BIC in one field", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "Required Elements, Payments Originating Overseas", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "clause 3.10", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.receiving-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, the Payments Originating Overseas row of the Required Elements table; FPS Reimbursement Rules Schedule 4 v3.0, clause 3.10. Both read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that a payment originating overseas is identified only by a BIC in tag 42 rather than a sort code, and the warning that failing to populate it correctly risks a money laundering or know your customer breach." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.pre-funded-account-equal-to-net-sender-cap", "id": "rule.pre-funded-account-equal-to-net-sender-cap", "rail": "uk-fps", "class": "Rule", "name": "Pre-funding must equal the net sender cap", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "section 6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-pfmi-self-assessment-2025", "section": "2.2, 2.2.2 and key consideration 8.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.dcsp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.bank-of-england", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.faster-payments-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, section 6; Pay.UK 2025 PFMI self-assessment, sections 2.2 and 2.2.2 and key consideration 8.2. Both read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that each settling participant holds cash equal to its net sender cap in a separate pre funded account which is drawn on only if a participant cannot meet its obligations." }, { "source": "uk-fps:src.payuk-pfmi-self-assessment-2025", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that banks and building societies hold Prefunding Accounts while non-bank payment service providers hold Settlement Collateralisation Accounts or Client Fund Accounts, backed by a Deed of Charge or, on the own funds model, a Single Settlement Trust Deed." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.providers-must-tell-consumers-and-change-their-terms", "id": "rule.providers-must-tell-consumers-and-change-their-terms", "rail": "uk-fps", "class": "Rule", "name": "Providers had to tell consumers about the right and write it into their terms", "statement": "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.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.psr-specific-direction-20-july-2024", "section": "paragraphs 5.1 to 5.5 and 6.1 to 6.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.directed-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.consumer", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "PSR Specific Direction 20 (July 2024), paragraphs 5.1 to 5.5 and 6.1 to 6.3, read 2026-09-20. The guidance the regulator said it would publish on what providers must tell consumers was not read [Unverified].", "confidence": "high" }, "currency": { "effective_since": "2024-10-07", "effective_to": null, "effective_note": "Specific Direction 20 (July 2024) came into force on 12 July 2024. The duty to inform existing consumers bit on 7 October 2024 and the deadline for amending contract terms was 9 April 2025.", "source_edition": "FPS Reimbursement Rules, Schedule 4, v3.0 dated 26 September 2024, read 2026-09-20, together with PSR Specific Direction 20 (July 2024) and the two PSR notices of value, all read the same day.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.psr-specific-direction-20-july-2024", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the 7 October 2024 deadline to inform existing consumers, the duty to inform new consumers before service begins, and the 9 April 2025 deadline to amend contract terms." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.qualifier-codes-signal-five-timescales", "id": "rule.qualifier-codes-signal-five-timescales", "rail": "uk-fps", "class": "Rule", "name": "A qualified acceptance signals one of five timescales, and the code values are not public", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "Required Elements, Availability of Funds to the Beneficiary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-certainty-of-fate-rule-clarification-2026-01", "section": "annex, rules 6.2a, 6.2b and 9.3.1", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.receiving-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, the Availability of Funds to the Beneficiary row of the Required Elements table; Certainty of Fate annex, rules 6.2 and 9.3.1, which name Appendix B section 7 as where the qualifier codes live. Both read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "primary_not_public": true, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.receiving-institution-decides-in-seconds", "id": "rule.receiving-institution-decides-in-seconds", "rail": "uk-fps", "class": "Rule", "name": "The receiving institution decides in seconds, and may accept with a qualification", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "Required Elements, Error Checking (Receiving Participant), Availability of Funds to the Beneficiary", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-certainty-of-fate-rule-clarification-2026-01", "section": "annex, rules 6.2 and 10.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.receiving-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "uk-fps:exc.rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, the Error Checking (Receiving Participant) and Availability of Funds rows of the Required Elements table; Pay.UK's Certainty of Fate proposed rule clarification, annex rules 6.2 and 10.1. Both read 2026-09-20. The clarification was open for feedback to 20 February 2026 and no outcome had been published when this record was written.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the three possible responses within seconds and the minimum checks expected for an unqualified acceptance." }, { "source": "uk-fps:src.payuk-certainty-of-fate-rule-clarification-2026-01", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the proposed clarification that a receiving institution must accept without qualification where payee account details can be checked in near real time and funds availability for the vast majority is certain, extending only in exceptional circumstances." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.receiving-provider-answers-an-information-request-by-the-25th-business-day", "id": "rule.receiving-provider-answers-an-information-request-by-the-25th-business-day", "rail": "uk-fps", "class": "Rule", "name": "An information request should be answered by the end of the 25th business day", "statement": "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.", "rests_on": "rule", "facet": "liability", "parameters": { "time_window": { "count": 25, "unit": "business_day", "from": "receipt", "text": "recommended by the end of the 25th business day after the claim was reported" } }, "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "clause 4.7", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.receiving-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "uk-fps:exc.app-scam-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "FPS Reimbursement Rules Schedule 4 v3.0, clause 4.7, read 2026-09-20.", "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).", "source_edition": "FPS Reimbursement Rules, Schedule 4, v3.0 dated 26 September 2024, read 2026-09-20, together with PSR Specific Direction 20 (July 2024) and the two PSR notices of value, all read the same day.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the recommended 25th business day response point, the duty to answer accurately and as soon as possible, and the sending provider's duty to state the final day to respond." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.receiving-provider-chooses-what-to-volunteer-and-when-to-repatriate", "id": "rule.receiving-provider-chooses-what-to-volunteer-and-when-to-repatriate", "rail": "uk-fps", "class": "Rule", "name": "Two choices belong to the receiving provider", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "clauses 4.2, 6.4 and 6.5", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.receiving-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "uk-fps:exc.app-scam-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "FPS Reimbursement Rules Schedule 4 v3.0, clauses 4.2, 6.4 and 6.5, read 2026-09-20. That no outer limit is put on the receiving provider's internal investigations is an absence in the text read [Inference]. Confidence is held at medium although the source is the operative rule, because the decision-points facet records judgement.", "confidence": "medium" }, "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).", "source_edition": "FPS Reimbursement Rules, Schedule 4, v3.0 dated 26 September 2024, read 2026-09-20, together with PSR Specific Direction 20 (July 2024) and the two PSR notices of value, all read the same day.", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.receiving-provider-may-respond-within-three-business-days", "id": "rule.receiving-provider-may-respond-within-three-business-days", "rail": "uk-fps", "class": "Rule", "name": "The receiving provider has three business days to volunteer what it knows", "statement": "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.", "rests_on": "rule", "facet": "liability", "parameters": { "time_window": { "count": 3, "unit": "business_day", "from": "receipt", "text": "to the end of the third business day after the consumer reported the claim" } }, "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "clauses 4.2, 4.3(1), 4.11 and 4.13", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.receiving-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "uk-fps:exc.app-scam-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "FPS Reimbursement Rules Schedule 4 v3.0, clauses 4.2, 4.3, 4.11 and 4.13, read 2026-09-20.", "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).", "source_edition": "FPS Reimbursement Rules, Schedule 4, v3.0 dated 26 September 2024, read 2026-09-20, together with PSR Specific Direction 20 (July 2024) and the two PSR notices of value, all read the same day.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the three business day opportunity to respond, that the sending provider cannot complete its assessment or close the claim before that period ends or all receiving providers answer, and that early payment still requires completing the assessment." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.reference-and-remittance-fields", "id": "rule.reference-and-remittance-fields", "rail": "uk-fps", "class": "Rule", "name": "What a payment can carry, and what the payee must be shown", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "Required Elements, Account Statement, Payment Information, Beneficiary Account Details", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.receiving-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, the Account Statement, Payment Information and Beneficiary Account Details rows of the Required Elements table, read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the 18, 31 and 140 character fields in tags 120, 62 and 121, the competitive status of the two optional fields, and the minimum statement detail of posting date, amount, remitter name and tag 120 reference." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.reimbursable-contribution-is-half-apportioned", "id": "rule.reimbursable-contribution-is-half-apportioned", "rail": "uk-fps", "class": "Rule", "name": "The receiving provider pays back half, split by where the money went", "statement": "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.", "rests_on": "rule", "facet": "liability", "parameters": { "liability_holder": { "role": "uk-fps:role.receiving-psp", "condition": "the sending provider has paid the reimbursable amount and has substantiated the claim with the data clause 5.3 requires", "text": "the receiving provider pays a share of half the reimbursable amount, apportioned by the value of the reimbursable payments it received" } }, "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "clauses 5.1, 5.3, 5.4, 5.5, 5.6 and 5.9", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.receiving-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "uk-fps:exc.app-scam-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "FPS Reimbursement Rules Schedule 4 v3.0, clauses 5.1 and 5.3 to 5.6 and 5.9, read 2026-09-20.", "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).", "source_edition": "FPS Reimbursement Rules, Schedule 4, v3.0 dated 26 September 2024, read 2026-09-20, together with PSR Specific Direction 20 (July 2024) and the two PSR notices of value, all read the same day.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the half share apportioned by value across receiving providers, the alternate calculation where no excess is applied and the victim is not vulnerable, and that the sending provider calculates and substantiates the figure." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.reimburse-within-five-business-days", "id": "rule.reimburse-within-five-business-days", "rail": "uk-fps", "class": "Rule", "name": "Five business days to pay the victim, unless the clock is stopped", "statement": "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.", "rests_on": "rule", "facet": "liability", "parameters": { "time_window": { "count": 5, "unit": "business_day", "from": "receipt", "text": "five business days from the victim reporting the claim, subject to the stop the clock provision" } }, "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "clauses 3.3, 4.3(2), 4.14 and 10.4 (Business day)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "uk-fps:exc.app-scam-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "FPS Reimbursement Rules Schedule 4 v3.0, clauses 3.3, 4.3, 4.14 and the definition of Business day in clause 10.4, read 2026-09-20.", "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).", "source_edition": "FPS Reimbursement Rules, Schedule 4, v3.0 dated 26 September 2024, read 2026-09-20, together with PSR Specific Direction 20 (July 2024) and the two PSR notices of value, all read the same day.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the five business day window from the victim's report, the stop the clock exception, and the definition of business day as excluding Saturday, Sunday and a UK bank holiday." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.reimbursement-does-not-affect-finality", "id": "rule.reimbursement-does-not-affect-finality", "rail": "uk-fps", "class": "Rule", "name": "The reimbursement requirement does not touch settlement finality", "statement": "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.", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "clause 2.6", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.receiving-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "uk-fps:exc.app-scam-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "FPS Reimbursement Rules Schedule 4 v3.0, clause 2.6, read 2026-09-20.", "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).", "source_edition": "FPS Reimbursement Rules, Schedule 4, v3.0 dated 26 September 2024, read 2026-09-20, together with PSR Specific Direction 20 (July 2024) and the two PSR notices of value, all read the same day.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-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 and does not alter a provider's other legal obligations under other regimes." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.reimbursement-overrides-the-wrong-identifier-defence", "id": "rule.reimbursement-overrides-the-wrong-identifier-defence", "rail": "uk-fps", "class": "Rule", "name": "The reimbursement duty overrides the wrong account number defence", "statement": "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.", "rests_on": "law", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.psrs-2017-part-7", "section": "regulation 90(6) and 90(7), with textual amendment note F34", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "uk-fps:exc.app-scam-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The Payment Services Regulations 2017, regulation 90(6) and (7) and the textual amendment note recording their insertion on 29 August 2023 by the Financial Services and Markets Act 2023, sections 72(11) and 86(2)(i), read on legislation.gov.uk 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "2023-08-29", "effective_to": null, "effective_note": "Regulation 90(6) and (7) were inserted on 29 August 2023 by the Financial Services and Markets Act 2023, section 72(11), as textual amendment note F34 on legislation.gov.uk records.", "source_edition": "The Payment Services Regulations 2017 (SI 2017/752), Part 7, current consolidated text on legislation.gov.uk read 2026-09-20.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.psrs-2017-part-7", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms regulation 90(6) and (7) as inserted, that a relevant requirement includes a direction under section 54 of the Financial Services (Banking Reform) Act 2013, and the textual amendment note dating the insertion to 29 August 2023." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.reimbursement-rules-bind-non-members", "id": "rule.reimbursement-rules-bind-non-members", "rail": "uk-fps", "class": "Rule", "name": "The reimbursement rules bind providers that are not scheme members", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "section 3 Application; clauses 2.2, 2.3, 2.4 and 2.5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.psr-specific-direction-20-july-2024", "section": "paragraphs 1.5, 8.1, 8.3 and 10.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.directed-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sponsoring-dcsp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "uk-fps:exc.app-scam-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "FPS Reimbursement Rules Schedule 4 v3.0, the Application heading in section 3 and clauses 2.2 to 2.5; PSR Specific Direction 20 (July 2024), paragraphs 1.5, 8.1, 8.3 and 10.1. Both read 2026-09-20.", "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).", "source_edition": "FPS Reimbursement Rules, Schedule 4, v3.0 dated 26 September 2024, read 2026-09-20, together with PSR Specific Direction 20 (July 2024) and the two PSR notices of value, all read the same day.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that Schedule 4 applies to every directed provider whether or not a scheme member, the registration and onboarding stages and their dates, and the sponsoring participant exception." }, { "source": "uk-fps:src.psr-specific-direction-20-july-2024", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the equal footing purpose for members and non-members, the 20 August 2024 registration deadline, and the direction's application to all providers that provide relevant accounts." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.rejection-and-return-code-lists-are-not-published", "id": "rule.rejection-and-return-code-lists-are-not-published", "rail": "uk-fps", "class": "Rule", "name": "The code lists live in a document Pay.UK does not publish", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-certainty-of-fate-rule-clarification-2026-01", "section": "annex, rules 6.2a, 6.2b, 9.3.1 and 10.1", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-pfmi-self-assessment-2025", "section": "key consideration 23.1", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.receiving-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.faster-payments-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps-reject:rail.uk-fps-reject", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps-return:rail.uk-fps-return", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Pay.UK's Certainty of Fate proposed rule clarification v1.0, annex rules 6.2 and 9.3.1 and 10.1; Pay.UK 2025 PFMI self-assessment, key consideration 23.1. Both read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it. Merged 2026-09-20: uk-fps-reject:rule.rejection-code-list-is-not-published stated the same thing from the same two Pay.UK documents, that the rejection code list sits in FPS Procedures Appendix B, FPS Codes, section 8.2, which Pay.UK does not publish, and was deleted; the nine uk-fps-reject records and the rejection Exception that named it now name this record, and the deleted record's binds link to the Faster Payments operator role was carried over onto this rail's own copy of that role. This record was kept because it is the union of the three: it names section 7 for the qualifier codes and section 8.2 for the rejection codes, covers the return reason as well, and cites annex rules 6.2a, 6.2b, 9.3.1 and 10.1 where the deleted record cited three of them. The deleted record also stated that every code record in the uk-fps-reject directory rests on independent public sources rather than the operator's text and is capped at medium confidence, which is the standing rule in docs/validator.md for a rail marked primary_not_public, and that Pay.UK does not publish the list, which is the first known gap on the uk-fps-reject Rail record. Merged 2026-09-20: uk-fps-return:rule.return-reason-list-is-not-published stated the same thing from the same two Pay.UK documents, that a return reason is required on every Return Payment and that Pay.UK does not publish the list of values, and was deleted; the eight uk-fps-return records and the Return Payment Exception that named it now name this record, and the deleted record's binds link to the Faster Payments operator role was carried over onto this rail's own copy of that role. The deleted record also stated that every record in the uk-fps-return directory rests on independent public sources rather than the operator's text and is capped at medium confidence, which is the standing rule in docs/validator.md for a rail marked primary_not_public, and that Pay.UK does not publish the list, which is the first known gap on the uk-fps-return Rail record.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "primary_not_public": true, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "uk-fps-reject:exc.rejection", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:rule.rejection-code-required", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:1114", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:1160", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:1162", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:1163", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:1164", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:1165", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:1170", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:1171", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:exc.return-payment", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000001", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000002", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000005", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000006", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000007", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000008", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000009", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000010", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:rule.repatriation-apportionment", "id": "rule.repatriation-apportionment", "rail": "uk-fps", "class": "Rule", "name": "Money recovered is shared so nobody profits", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "clauses 6.1, 6.2 and 6.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.receiving-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "uk-fps:exc.app-scam-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "FPS Reimbursement Rules Schedule 4 v3.0, clauses 6.1 to 6.3, read 2026-09-20.", "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).", "source_edition": "FPS Reimbursement Rules, Schedule 4, v3.0 dated 26 September 2024, read 2026-09-20, together with PSR Specific Direction 20 (July 2024) and the two PSR notices of value, all read the same day.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the apportionment of recovered funds between sending provider, receiving provider and victim, the governing principle that nobody receives back more than they paid out, and that a court, regulator, law enforcement or disputes body instruction overrides it." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.repatriation-within-three-business-days-of-concluding-investigations", "id": "rule.repatriation-within-three-business-days-of-concluding-investigations", "rail": "uk-fps", "class": "Rule", "name": "Recovered money moves within three business days of the receiving provider finishing its investigations", "statement": "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.", "rests_on": "rule", "facet": "liability", "parameters": { "time_window": { "count": 3, "unit": "business_day", "from": "determination", "text": "three business days from the receiving provider concluding all internal investigations and approvals" } }, "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "clauses 6.4 and 6.5 and 10.4 (Claim closed, pending repatriation)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.receiving-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "uk-fps:exc.app-scam-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "FPS Reimbursement Rules Schedule 4 v3.0, clauses 6.4 and 6.5 and the definition of Claim closed, pending repatriation in clause 10.4, read 2026-09-20. The 13 month dormancy is not typed: Orca Core v0's time_window has no month unit.", "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).", "source_edition": "FPS Reimbursement Rules, Schedule 4, v3.0 dated 26 September 2024, read 2026-09-20, together with PSR Specific Direction 20 (July 2024) and the two PSR notices of value, all read the same day.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the three business day window from the receiving provider concluding its own investigations, that no limit is stated on how long those investigations may run, and the 13 month dormancy before a claim closes without repatriation." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.retry-later-the-same-day-on-insufficient-funds", "id": "rule.retry-later-the-same-day-on-insufficient-funds", "rail": "uk-fps", "class": "Rule", "name": "A participant retries a standing order or forward dated payment later the same day", "statement": "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.", "rests_on": "guidance", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "sections 5.1, 5.2 and 5.3; Required Elements, Paying Customer Funds", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "uk-fps:txn.standing-order-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "uk-fps:txn.forward-dated-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, sections 5.1, 5.2 and 5.3 and the Paying Customer Funds row of the Required Elements table, read 2026-09-20. The Financial Conduct Authority requirement Pay.UK points at was not read [Unverified], which is why this Rule rests on guidance rather than on law.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the same day retry for standing orders and forward dated payments on insufficient funds, attributed to a Financial Conduct Authority requirement, and that an attended single immediate payment carries no such obligation." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.return-blocked-by-a-transaction-limit-must-be-agreed", "id": "rule.return-blocked-by-a-transaction-limit-must-be-agreed", "rail": "uk-fps", "class": "Rule", "name": "A limit that blocks a full return has to be worked around by agreement", "statement": "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.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-certainty-of-fate-rule-clarification-2026-01", "section": "annex, rule 10.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.receiving-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "uk-fps:exc.return-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "uk-fps:txn.return-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps-return:rule.return-is-a-new-payment", "note": "The wider rule, from the same source at the same section. That record states the whole of annex rule 10.1, including this agreement duty as one clause; this one is the duty on its own and adds that the limit neither excuses keeping the money nor permits a partial Return Payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Pay.UK's Certainty of Fate proposed rule clarification v1.0, annex rule 10.1, read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "2026-01-01", "effective_to": null, "effective_note": "Pay.UK's Certainty of Fate paper of January 2026 prints this rule as it already stands, with the January 2026 proposals marked separately in bold; this provision is in the existing wording, not in the proposal. The FPS Rules carry no public date, so the date here is the month of the paper that reproduced the rule, and is not a date the rule took effect [Inference].", "source_edition": "Pay.UK's Certainty of Fate proposed rule clarification v1.0, January 2026, read 2026-09-20.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-certainty-of-fate-rule-clarification-2026-01", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that where transaction limits prevent returning the whole payment as a Return Payment, the returning institution must contact the originating institution to agree how the funds are returned." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps-return:rule.return-is-a-new-payment", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:rule.return-payment-is-a-new-payment", "id": "rule.return-payment-is-a-new-payment", "rail": "uk-fps", "class": "Rule", "name": "A return is a new payment, never a reversal", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "section 5.4; Required Elements, Returns", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-certainty-of-fate-rule-clarification-2026-01", "section": "annex, rule 10.1", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.receiving-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "uk-fps:exc.return-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "uk-fps:txn.return-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, section 5.4 and the Returns row of the Required Elements table; Certainty of Fate annex, rule 10.1. Both read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that a Return Payment is a new payment referencing the original rather than a reversal, sent where possible via Faster Payments." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps-return:rule.return-is-a-new-payment", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:rule.return-payment-within-1-to-3-working-days", "id": "rule.return-payment-within-1-to-3-working-days", "rail": "uk-fps", "class": "Rule", "name": "A Return Payment goes within one to three working days", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "section 5.4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.receiving-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "uk-fps:exc.return-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "uk-fps:txn.return-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "uk-fps-return:exc.return-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps-return:role.receiving-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, section 5.4, read 2026-09-20. No typed time window is carried: the parameter holds one count, and this deadline is a range whose value turns on a response Orca cannot see.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it. Merged 2026-09-20: uk-fps-return:rule.return-within-1-to-3-working-days stated the same provision from the same source and section in the uk-fps-return directory and was deleted; the eight uk-fps-return return reason records that named it now name this record, and the deleted record's own part_of and binds links moved here, so this Rule is part of the return path as both directories hold it. Its sourced_from link was not moved: it named the uk-fps-return copy of Faster Payments System Principles v11, the same document this record already cites at the same section.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the one to three working day window for a Return Payment, depending on the receiving participant's response to the original payment." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps-return:00000001", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000002", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000005", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000006", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000007", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000008", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000009", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000010", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:rule.schedule-4-is-a-scheme-rule-the-regulator-enforces", "id": "rule.schedule-4-is-a-scheme-rule-the-regulator-enforces", "rail": "uk-fps", "class": "Rule", "name": "Schedule 4 is part of the FPS Rules but the regulator, not Pay.UK, enforces it", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "clauses 9.1, 9.2 and 9.3 and clause 2.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.faster-payments-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.psr", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "FPS Reimbursement Rules Schedule 4 v3.0, clauses 2.1, 9.1, 9.2 and 9.3, read 2026-09-20.", "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).", "source_edition": "FPS Reimbursement Rules, Schedule 4, v3.0 dated 26 September 2024, read 2026-09-20, together with PSR Specific Direction 20 (July 2024) and the two PSR notices of value, all read the same day.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms clause 9.1's incorporation into the FPS Rules, the four changes in clause 9.2 including enforcement passing to the regulator, and clause 9.3's preservation of other legal obligations." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.scheme-return-sent-only-by-the-infrastructure", "id": "rule.scheme-return-sent-only-by-the-infrastructure", "rail": "uk-fps", "class": "Rule", "name": "Only the central infrastructure sends a Scheme Return Payment", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "section 5.5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.central-infrastructure-provider", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "uk-fps:exc.scheme-return-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "uk-fps:txn.scheme-return-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, section 5.5, read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that only the central infrastructure sends a Scheme Return Payment, and only to return funds for an asynchronous payment a participant received but rejected." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.sending-provider-judges-the-scam-claim", "id": "rule.sending-provider-judges-the-scam-claim", "rail": "uk-fps", "class": "Rule", "name": "The sending provider judges gross negligence and vulnerability, alone", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "clauses 3.6, 3.11, 4.2, 4.3, 4.5 and 2.6", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "uk-fps:exc.app-scam-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "FPS Reimbursement Rules Schedule 4 v3.0, clauses 2.6, 3.6, 3.11, 4.2, 4.3 and 4.5, read 2026-09-20. That there is no appeal route inside the rules is an absence in the text read, not a statement in it [Inference]. Confidence is held at medium although the source is the operative rule, because the decision-points facet records judgement.", "confidence": "medium" }, "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).", "source_edition": "FPS Reimbursement Rules, Schedule 4, v3.0 dated 26 September 2024, read 2026-09-20, together with PSR Specific Direction 20 (July 2024) and the two PSR notices of value, all read the same day.", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.settlement-in-central-bank-money-at-boe", "id": "rule.settlement-in-central-bank-money-at-boe", "rail": "uk-fps", "class": "Rule", "name": "Settlement is in central bank money at the Bank of England", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-pfmi-self-assessment-2025", "section": "2.2, 2.2.2 and key consideration 8.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "sections 4.1 and 6", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.dcsp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.bank-of-england", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Pay.UK 2025 PFMI self-assessment, sections 2.2 and 2.2.2 and key consideration 8.2; Faster Payments System Principles v11, sections 4.1 and 6. Both read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-pfmi-self-assessment-2025", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms settlement in central bank money at the Bank of England, the contract naming the Bank as settlement service provider, and the contingency of seeking extensions or delaying cycles rather than unwinding payments." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.sort-code-directory-must-be-refreshed-weekly", "id": "rule.sort-code-directory-must-be-refreshed-weekly", "rail": "uk-fps", "class": "Rule", "name": "Participants must refresh sort code data every week", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "section 8; section 4.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.dcsp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.dcnsp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, sections 4.3 and 8, read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the mandatory weekly refresh of sort code reference data from the Extended Industry Sort Code Directory, and that settling participants maintain the directory entries of indirect agencies including those sponsored by a non-settling participant." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.standing-orders-90-percent-before-06-00", "id": "rule.standing-orders-90-percent-before-06-00", "rail": "uk-fps", "class": "Rule", "name": "At least nine in ten standing orders go out between midnight and 06:00", "statement": "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.", "rests_on": "rule", "facet": "hours", "parameters": { "limit": { "rate": 90, "unit": "percent", "measured_over": "a sending participant's standing order payments", "text": "at least 90 percent submitted between midnight and 06:00" } }, "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "section 5.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "uk-fps:txn.standing-order-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, section 5.2, read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the 90 percent between midnight and 06:00 requirement and the retry exception for insufficient funds." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.standing-orders-weekdays-only", "id": "rule.standing-orders-weekdays-only", "rail": "uk-fps", "class": "Rule", "name": "Standing orders run on weekdays only", "statement": "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.", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "section 5.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "uk-fps:txn.standing-order-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, section 5.2, read 2026-09-20. The contrast with the reimbursement rules' business day is Orca's own observation from the definition in Schedule 4 clause 10.4 [Inference].", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that standing orders execute only on weekdays excluding public holidays in England and Wales, held back to the next working day otherwise." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.statutory-liability-for-non-execution-or-late-execution", "id": "rule.statutory-liability-for-non-execution-or-late-execution", "rail": "uk-fps", "class": "Rule", "name": "The payer's provider answers for a payment that did not arrive", "statement": "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.", "rests_on": "law", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.psrs-2017-part-7", "section": "regulation 91(1) to 91(8)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.receiving-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The Payment Services Regulations 2017, regulation 91, read on legislation.gov.uk 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "Unknown: the consolidated text read does not state when this regulation commenced", "effective_to": null, "effective_note": "The consolidated text on legislation.gov.uk carries no commencement note on regulation 91, so the date it first applied is [Unverified] here.", "source_edition": "The Payment Services Regulations 2017 (SI 2017/752), Part 7, current consolidated text on legislation.gov.uk read 2026-09-20.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.psrs-2017-part-7", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms regulation 91's liability rule for a payer initiated payment, the refund and account restoration duty, the value dating rules, and the tracing duty regardless of liability." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.statutory-refund-for-an-unauthorised-transaction", "id": "rule.statutory-refund-for-an-unauthorised-transaction", "rail": "uk-fps", "class": "Rule", "name": "An unauthorised payment must be refunded by the end of the next business day", "statement": "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.", "rests_on": "law", "facet": "refund", "parameters": { "time_window": { "count": 1, "unit": "business_day", "from": "discovery", "text": "by the end of the business day after the provider becomes aware of the unauthorised transaction" } }, "relations": [ { "type": "sourced_from", "to": "uk-fps:src.psrs-2017-part-7", "section": "regulations 76(1) to 76(4) and 77(1) to 77(4)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The Payment Services Regulations 2017, regulations 76 and 77, read on legislation.gov.uk 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "Unknown: the consolidated text read does not state when this regulation commenced", "effective_to": null, "effective_note": "The consolidated text on legislation.gov.uk carries no commencement note on regulations 76 and 77, so the date they first applied is [Unverified] here. The page lists amendments to Part 7 dated 13 August 2017, 13 January 2018, 31 December 2020, 29 August 2023 and 30 October 2024.", "source_edition": "The Payment Services Regulations 2017 (SI 2017/752), Part 7, current consolidated text on legislation.gov.uk read 2026-09-20.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.psrs-2017-part-7", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms regulations 76 and 77: the refund and restoration duty, the next business day deadline, the money laundering reporting exception, the 35 pound payer liability cap, and full payer liability for fraud or gross negligence." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.stop-the-clock-grounds", "id": "rule.stop-the-clock-grounds", "rail": "uk-fps", "class": "Rule", "name": "Six grounds let the sending provider stop the clock, as often as needed", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "clauses 4.5, 4.6, 4.8, 4.9 and 4.10", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "uk-fps:exc.app-scam-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "FPS Reimbursement Rules Schedule 4 v3.0, clauses 4.5, 4.6, 4.8, 4.9 and 4.10, read 2026-09-20.", "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).", "source_edition": "FPS Reimbursement Rules, Schedule 4, v3.0 dated 26 September 2024, read 2026-09-20, together with PSR Specific Direction 20 (July 2024) and the two PSR notices of value, all read the same day.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the six permitted grounds for pausing the clock, that the clock restarts once all requested information is in and nothing further is sought, that it may be paused as many times as needed, and the record-keeping duty." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.system-value-ceiling-one-million", "id": "rule.system-value-ceiling-one-million", "rail": "uk-fps", "class": "Rule", "name": "The central infrastructure rejects a payment above GBP 1,000,000", "statement": "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.", "rests_on": "rule", "facet": "limits", "parameters": { "limit": { "amount": 1000000, "currency": "GBP", "per": "entry", "text": "GBP 1,000,000 for a single payment, enforced by the central infrastructure" } }, "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-pfmi-self-assessment-2025", "section": "2.2.2 and its footnote 7", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-transaction-limits-page", "section": "opening paragraph", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "Required Elements, Limits (Individual Payment Amount)", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.central-infrastructure-provider", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "uk-fps:exc.rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "uk-fps:txn.single-immediate-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "uk-fps:txn.standing-order-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "uk-fps:txn.forward-dated-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "uk-fps:txn.direct-corporate-access", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Pay.UK 2025 PFMI self-assessment, section 2.2.2 and its footnote 7; Pay.UK's transaction limits page; Faster Payments System Principles v11, the Limits row of the Required Elements table, which states that the infrastructure enforces a maximum and points at the website for the figure. 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 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].", "source_edition": "Pay.UK 2025 PFMI self-assessment (published November 2025); Pay.UK's Faster Payment System transaction limits page as read 2026-09-20; Faster Payments System Principles v11.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-pfmi-self-assessment-2025", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the GBP 1,000,000 system limit and that it was raised from GBP 250,000 in February 2022." }, { "source": "uk-fps:src.payuk-fps-transaction-limits-page", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms it is now possible to send individual payments of up to 1 million pounds using the Faster Payments System, and that organisations offering the service can set their own lower limits." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.thirteen-month-reporting-limit", "id": "rule.thirteen-month-reporting-limit", "rail": "uk-fps", "class": "Rule", "name": "A claim reported more than 13 months after the last payment is out of the regime", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "clauses 3.4, 3.8 and 3.11(6)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.consumer", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "uk-fps:exc.app-scam-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "FPS Reimbursement Rules Schedule 4 v3.0, clauses 3.4, 3.8 and 3.11, read 2026-09-20. The 13 months are not carried as a typed time window: Orca Core v0's time_window has no month unit.", "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).", "source_edition": "FPS Reimbursement Rules, Schedule 4, v3.0 dated 26 September 2024, read 2026-09-20, together with PSR Specific Direction 20 (July 2024) and the two PSR notices of value, all read the same day.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the 13 month limit running from the final payment of the claim, the 7 October 2024 start date, and that a payment reimbursed outside the limit is voluntary regardless of vulnerability." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.three-response-outcomes", "id": "rule.three-response-outcomes", "rail": "uk-fps", "class": "Rule", "name": "Every payment gets one of three answers, and one of them is neither yes nor no", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "Required Elements, Availability of Funds to the Beneficiary, Fate of Payment, Customer Messaging", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-certainty-of-fate-rule-clarification-2026-01", "section": "section 3 and annex, rules 6.2 and 9.3.1", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.receiving-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, the Availability of Funds to the Beneficiary, Fate of Payment and Customer Messaging rows of the Required Elements table; Pay.UK's Certainty of Fate proposed rule clarification, section 3 and annex rules 6.2 and 9.3.1. Both read 2026-09-20. The response time itself is defined in the FPS Procedures and Technical Specifications, which are not public.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "primary_not_public": true, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "uk-fps-reject:rule.respond-within-a-few-seconds", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:rule.uk-to-uk-scope-of-the-reimbursement-requirement", "id": "rule.uk-to-uk-scope-of-the-reimbursement-requirement", "rail": "uk-fps", "class": "Rule", "name": "The requirement covers a UK consumer account paying a UK account", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "clauses 3.10 and 10.4 (Relevant account, Consumer, Account controlled by the consumer)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "uk-fps:exc.app-scam-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "FPS Reimbursement Rules Schedule 4 v3.0, clause 3.10 and the definitions of Relevant account, Consumer and Account controlled by the consumer in clause 10.4, read 2026-09-20.", "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).", "source_edition": "FPS Reimbursement Rules, Schedule 4, v3.0 dated 26 September 2024, read 2026-09-20, together with PSR Specific Direction 20 (July 2024) and the two PSR notices of value, all read the same day.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the five features an in-scope payment must have and the definitions of relevant account, consumer and account controlled by the consumer." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.voluntary-reimbursement-is-outside-the-regime", "id": "rule.voluntary-reimbursement-is-outside-the-regime", "rail": "uk-fps", "class": "Rule", "name": "Anything paid outside the rules is voluntary, and the receiving side owes nothing toward it", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "section": "clauses 3.7, 3.8, 3.9, 5.2 and 10.4 (Voluntary reimbursement)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.receiving-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "uk-fps:exc.app-scam-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:rule.maximum-level-of-reimbursement", "note": "That record sets the ceiling this record's first limb refers to, GBP 85,000 per claim, and takes it from the regulator's notice of value rather than from Schedule 4.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "FPS Reimbursement Rules Schedule 4 v3.0, clauses 3.7 to 3.9, clause 5.2 and the definition of Voluntary reimbursement in clause 10.4, read 2026-09-20.", "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).", "source_edition": "FPS Reimbursement Rules, Schedule 4, v3.0 dated 26 September 2024, read 2026-09-20, together with PSR Specific Direction 20 (July 2024) and the two PSR notices of value, all read the same day.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the definition of a voluntary reimbursement, that it falls outside the reimbursement requirement, and that the receiving provider owes nothing toward it, including a payment made after a court or dispute resolution decision following claim closure." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:rule.maximum-level-of-reimbursement", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:rule.who-participates-today", "id": "rule.who-participates-today", "rail": "uk-fps", "class": "Rule", "name": "Who is on the rail", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-participant-list-page", "section": "the Faster Payment System list", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-pfmi-self-assessment-2025", "section": "2.2.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-overview-page", "section": "opening description", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.faster-payments-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Pay.UK's Faster Payment participants page, counted by Orca from the Faster Payment System list on 2026-09-20 (47 entries); Pay.UK 2025 PFMI self-assessment, section 2.2.2; Pay.UK's Faster Payment System page. All read 2026-09-20. The participant list page carries no date and no access class, so the count is a reading of a live page.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-20", "effective_to": null, "effective_note": "Pay.UK's participant list page carries no date; the 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.", "source_edition": "Pay.UK's Faster Payment participants page and Faster Payment System page as read 2026-09-20; Pay.UK 2025 PFMI self-assessment.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-participant-list-page", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms 47 organisations listed as Faster Payment System participants, counted from the page on 2026-09-20." }, { "source": "uk-fps:src.payuk-pfmi-self-assessment-2025", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms 46 direct participants as at end August 2025 and about 300 further institutions reaching FPS through agency arrangements." }, { "source": "uk-fps:src.payuk-fps-overview-page", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms direct participation more than tripling since an access programme launched in 2014, the first non-bank direct participant joining in 2018, and 5.55 billion payments worth 4.84 trillion pounds carried in 2025." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:rule.wrong-unique-identifier-recovery-duty", "id": "rule.wrong-unique-identifier-recovery-duty", "rail": "uk-fps", "class": "Rule", "name": "A payment sent to the wrong account number is the payer's risk, with a duty to try to get it back", "statement": "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.", "rests_on": "law", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "uk-fps:src.psrs-2017-part-7", "section": "regulation 90(1) to 90(5)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.sending-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.receiving-psp", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The Payment Services Regulations 2017, regulation 90(1) to (5), read on legislation.gov.uk 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "Unknown: the consolidated text read does not state when this regulation commenced", "effective_to": null, "effective_note": "The consolidated text on legislation.gov.uk carries no commencement note on regulation 90(1) to (5). Paragraphs (6) and (7) of the same regulation were inserted later, on 29 August 2023, and are recorded separately.", "source_edition": "The Payment Services Regulations 2017 (SI 2017/752), Part 7, current consolidated text on legislation.gov.uk read 2026-09-20.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.psrs-2017-part-7", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms regulation 90(1) to (5): deemed correct execution on the identifier given, the recovery duty and right to charge, the payee provider's co-operation duty, and the duty to give the payer information if recovery fails." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps:src.payuk-certainty-of-fate-rule-clarification-2026-01", "id": "src.payuk-certainty-of-fate-rule-clarification-2026-01", "rail": "uk-fps", "class": "RuleSource", "name": "Pay.UK's work on Certainty of Fate to support A2A retail transactions: proposed rule clarification, v1.0", "summary": "A Pay.UK consultation paper whose annex sets out four FPS Rules in their current wording and with proposed additions marked, covering beneficiary accounts, the fate of a single immediate payment, and the receiving institution's general obligations. It is the only public document read that names the code lists by their place in the FPS Procedures and that gives the near real time response guideline in figures. The proposals were open for feedback until 20 February 2026 and no outcome had been published when this record was written.", "publisher": "Pay.UK Limited", "url": "https://www.wearepay.uk/wp-content/uploads/2026/01/Pay.UK-CoF-Proposed-Rule-Clarification-January-2026.pdf", "source_class": "public_primary", "kind": "consultation_paper", "edition": "v1.0, January 2026", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, fetched and read in full on 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for the uk-fps rail. A RuleSource describes one edition of one document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "v1.0, January 2026", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:exc.rejection", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:exc.return-payment", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:role.receiving-fps-institution", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:role.sending-fps-institution", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.near-real-time-guideline-10-and-15-seconds", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.partial-return-needs-the-originators-agreement", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.qualifier-codes-signal-five-timescales", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.receiving-institution-decides-in-seconds", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.rejection-and-return-code-lists-are-not-published", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.return-blocked-by-a-transaction-limit-must-be-agreed", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.return-payment-is-a-new-payment", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.three-response-outcomes", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:txn.return-payment", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:src.payuk-confirmation-of-payee-faqs", "id": "src.payuk-confirmation-of-payee-faqs", "rail": "uk-fps", "class": "RuleSource", "name": "Pay.UK, Confirmation of Payee FAQs", "summary": "Pay.UK's public questions and answers on the Confirmation of Payee account name checking overlay: the four outcomes a payer can be shown, which payment systems it covers, who may join and how, what secondary reference data is for, and Pay.UK's warning that a name check does not by itself decide whether a later loss is reimbursed.", "publisher": "Pay.UK Limited", "url": "https://www.wearepay.uk/what-we-do/overlay-services/confirmation-of-payee/faqs/", "source_class": "public_primary", "kind": "web_page", "edition": "live page as read 2026-09-20; the page carries no date", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, fetched and read in full on 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for the uk-fps rail. A RuleSource describes one edition of one document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "live page as read 2026-09-20; the page carries no date", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:rule.confirmation-of-payee-gives-the-payer-four-outcomes", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "uk-fps:src.payuk-fps-overview-page", "id": "src.payuk-fps-overview-page", "rail": "uk-fps", "class": "RuleSource", "name": "Pay.UK, Faster Payment System", "summary": "Pay.UK's overview page for the rail: when it launched, that it runs day and night all year, the system value ceiling, the growth in direct participation since the 2014 access programme, the arrival of the first non-bank direct participant in 2018, and the volume and value the system carried in 2025.", "publisher": "Pay.UK Limited", "url": "https://www.wearepay.uk/what-we-do/payment-systems/faster-payment-system/", "source_class": "public_primary", "kind": "web_page", "edition": "live page as read 2026-09-20; the page carries no date", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, fetched and read in full on 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for the uk-fps rail. A RuleSource describes one edition of one document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "live page as read 2026-09-20; the page carries no date", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:rule.clearing-24-7", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.who-participates-today", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "uk-fps:src.payuk-fps-participant-list-page", "id": "src.payuk-fps-participant-list-page", "rail": "uk-fps", "class": "RuleSource", "name": "Pay.UK, Faster Payment participants", "summary": "A live Pay.UK page listing the organisations that participate in the Faster Payment System, alongside separate lists for Bacs and the Image Clearing System. The page names the organisations and does not say which access class each holds.", "publisher": "Pay.UK Limited", "url": "https://www.wearepay.uk/what-we-do/payment-systems/faster-payment-system/payment-system-participant-list/", "source_class": "public_primary", "kind": "web_page", "edition": "live page as read 2026-09-20; the page carries no date", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, fetched and read in full on 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for the uk-fps rail. A RuleSource describes one edition of one document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "live page as read 2026-09-20; the page carries no date", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:rule.who-participates-today", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "uk-fps:src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "id": "src.payuk-fps-reimbursement-rules-schedule-4-v3-0", "rail": "uk-fps", "class": "RuleSource", "name": "FPS Reimbursement Rules, Schedule 4, v3.0", "summary": "Pay.UK's own scheme rule for reimbursing victims of authorised push payment scams over Faster Payments. Clause 9.1 states that it is incorporated into and forms part of the FPS Rules, Rules for the Faster Payments Service, which makes it the only part of the FPS rulebook Pay.UK publishes. It sets who must reimburse, in what time, up to what value, on what exceptions, how much the receiving institution pays back, and how recovered money is shared. Written under a requirement made by the Payment Systems Regulator and enforced by that regulator rather than by Pay.UK.", "publisher": "Pay.UK Limited", "url": "https://www.wearepay.uk/wp-content/uploads/2024/09/FPS-Reimbursement-Rules-Schedule-4-v3.0.pdf", "source_class": "authoritative_primary", "kind": "scheme_rulebook_schedule", "edition": "v3.0, dated 26 September 2024", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, fetched and read in full on 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for the uk-fps rail. A RuleSource describes one edition of one document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "v3.0, dated 26 September 2024", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:rail.uk-fps", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:exc.app-scam-claim", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:role.consumer", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:role.directed-psp", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:role.faster-payments-operator", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:role.fca", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:role.psr", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:role.receiving-psp", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:role.sending-psp", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:role.sponsoring-dcsp", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.app-reimbursement-requirement", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.claim-decided-and-closed-by-the-35th-business-day", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.claim-excess-up-to-100", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.consumer-standard-of-caution-exception", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.contribution-paid-within-five-business-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.directed-provider-population-is-wider-than-membership", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.maximum-level-of-reimbursement", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.no-excess-for-a-vulnerable-consumer", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.notify-the-receiving-provider-within-two-business-hours", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.operator-monitors-compliance-and-reports-to-the-regulator", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.other-grounds-a-claim-is-not-reimbursable", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.other-legal-regimes-are-not-displaced", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.outcome-must-be-told-to-the-consumer-in-writing", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.payment-originating-overseas-carries-a-bic-in-tag-42", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.receiving-provider-answers-an-information-request-by-the-25th-business-day", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.receiving-provider-chooses-what-to-volunteer-and-when-to-repatriate", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.receiving-provider-may-respond-within-three-business-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.reimbursable-contribution-is-half-apportioned", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.reimburse-within-five-business-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.reimbursement-does-not-affect-finality", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.reimbursement-rules-bind-non-members", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.repatriation-apportionment", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.repatriation-within-three-business-days-of-concluding-investigations", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.schedule-4-is-a-scheme-rule-the-regulator-enforces", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.sending-provider-judges-the-scam-claim", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.stop-the-clock-grounds", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.thirteen-month-reporting-limit", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.uk-to-uk-scope-of-the-reimbursement-requirement", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.voluntary-reimbursement-is-outside-the-regime", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "uk-fps:src.payuk-fps-system-principles-v11", "id": "src.payuk-fps-system-principles-v11", "rail": "uk-fps", "class": "RuleSource", "name": "Faster Payments System Principles, FPS information guide, v11", "summary": "Pay.UK's public guide to how the Faster Payment System works: the three access classes, the payment types, settlement, the elements every payment must carry, the response a receiving participant must give, and the participation fees. Its own section 1.4 says it is not a controlling specification and that the Scheme Procedures, Functional Specification and Rules take precedence over it, so it describes the rail rather than governing it.", "publisher": "Pay.UK Limited", "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", "kind": "information_guide", "edition": "v11, 2 January 2026", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, fetched and read in full on 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for the uk-fps rail. A RuleSource describes one edition of one document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "v11, 2 January 2026", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:rail.uk-fps", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:exc.bank-error-recovery", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:exc.credit-payment-recovery", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:exc.rejection", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:exc.return-payment", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:exc.scheme-return-payment", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:role.bank-of-england", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:role.central-infrastructure-provider", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:role.dcnsp", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:role.dcsp", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:role.faster-payments-operator", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:role.fca", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:role.indirect-agency", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:role.receiving-fps-institution", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:role.sending-fps-institution", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:role.sponsoring-dcsp", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.attended-payer-told-fate-within-15-seconds", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.bank-error-recovery-for-payments-sent-in-bulk-by-mistake", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.cass-redirection-happens-inside-the-infrastructure", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.clearing-24-7", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.confirmation-of-payee-gives-the-payer-four-outcomes", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.credit-payment-recovery-is-not-a-reversal", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.dcnsp-and-indirect-access", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.dcnsp-settles-through-its-sponsor", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.dcsp-eligibility", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.deferred-net-settlement-three-times-each-working-day", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.fraud-and-money-laundering-holds-are-each-providers-own", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.irrevocable-on-submission-to-ci", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.iso-8583-not-iso-20022", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.net-sender-cap-set-by-each-participant", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.no-recall-and-no-cancellation-once-submitted", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.no-revocation-messaging", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.onboarding-takes-9-to-12-months", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.participants-set-their-own-lower-limits", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.payment-originating-overseas-carries-a-bic-in-tag-42", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.pre-funded-account-equal-to-net-sender-cap", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.qualifier-codes-signal-five-timescales", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.receiving-institution-decides-in-seconds", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.reference-and-remittance-fields", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.retry-later-the-same-day-on-insufficient-funds", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.return-payment-is-a-new-payment", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.return-payment-within-1-to-3-working-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.scheme-return-sent-only-by-the-infrastructure", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.settlement-in-central-bank-money-at-boe", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.sort-code-directory-must-be-refreshed-weekly", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.standing-orders-90-percent-before-06-00", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.standing-orders-weekdays-only", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.system-value-ceiling-one-million", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.three-response-outcomes", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:txn.direct-corporate-access", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:txn.forward-dated-payment", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:txn.return-payment", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:txn.scheme-return-payment", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:txn.single-immediate-payment", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:txn.standing-order-payment", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "uk-fps:src.payuk-fps-transaction-limits-page", "id": "src.payuk-fps-transaction-limits-page", "rail": "uk-fps", "class": "RuleSource", "name": "Pay.UK, Faster Payment System transaction limits", "summary": "A live Pay.UK page stating the system maximum for a single Faster Payment and listing, organisation by organisation, the personal and business limits each directly connected participant applies by channel. The per participant figures are the participants' own commercial settings and move without notice.", "publisher": "Pay.UK Limited", "url": "https://www.wearepay.uk/what-we-do/payment-systems/faster-payment-system/transaction-limits/", "source_class": "public_primary", "kind": "web_page", "edition": "live page as read 2026-09-20; the page carries no date", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, fetched and read in full on 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for the uk-fps rail. A RuleSource describes one edition of one document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "live page as read 2026-09-20; the page carries no date", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:rule.participants-set-their-own-lower-limits", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.system-value-ceiling-one-million", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "uk-fps:src.payuk-pfmi-self-assessment-2025", "id": "src.payuk-pfmi-self-assessment-2025", "rail": "uk-fps", "class": "RuleSource", "name": "2025 PFMI self-assessment of Pay.UK", "summary": "Pay.UK's assessment of Bacs, the Faster Payment System and the Image Clearing System against the CPMI-IOSCO Principles for Financial Market Infrastructures, produced for the Bank of England. It is the clearest public statement of where FPS irrevocability and settlement finality attach, when net settlement runs, which standard the rail uses, and on what terms the FPS rules are available.", "publisher": "Pay.UK Limited", "url": "https://www.wearepay.uk/wp-content/uploads/2025/11/2025-PFMI-self-assessment-of-Pay.UK_.pdf", "source_class": "public_primary", "kind": "regulatory_self_assessment", "edition": "position as at end of August 2025, published November 2025", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, fetched and read in full on 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for the uk-fps rail. A RuleSource describes one edition of one document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "position as at end of August 2025, published November 2025", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:rail.uk-fps", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:role.bank-of-england", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:role.central-infrastructure-provider", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:role.dcnsp", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:role.dcsp", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:role.faster-payments-operator", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:role.psr", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.dcnsp-settles-through-its-sponsor", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.deferred-net-settlement-three-times-each-working-day", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.designated-for-settlement-finality", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.irrevocable-on-submission-to-ci", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.iso-8583-not-iso-20022", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.net-sender-cap-set-by-each-participant", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.net-settlement-final-at-rtgs-timestamp", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.no-recall-and-no-cancellation-once-submitted", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.no-revocation-messaging", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.pre-funded-account-equal-to-net-sender-cap", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.rejection-and-return-code-lists-are-not-published", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.settlement-in-central-bank-money-at-boe", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.system-value-ceiling-one-million", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.who-participates-today", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:txn.direct-corporate-access", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:txn.forward-dated-payment", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:txn.single-immediate-payment", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:txn.standing-order-payment", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:src.psr-specific-direction-17-consolidated-july-2026", "id": "src.psr-specific-direction-17-consolidated-july-2026", "rail": "uk-fps", "class": "RuleSource", "name": "PSR Specific Direction 17, consolidated text as it would be varied, July 2026", "summary": "The regulator's direction obliging named payment service providers to offer Confirmation of Payee, published in July 2026 as a consolidated text showing the changes a further direction would make: removing the expiry date and adding a third group of providers. It is a consultation document, so the marked changes are a proposal and not a rule. The October 2022 direction it consolidates was not read.", "publisher": "Payment Systems Regulator", "url": "https://www.psr.org.uk/media/aoudmk01/specific-direction-17-july-2026-consolidated.pdf", "source_class": "public_primary", "kind": "consultation_draft", "edition": "consolidated text published July 2026 alongside consultation CP26/2", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, fetched and read in full on 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for the uk-fps rail. A RuleSource describes one edition of one document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "consolidated text published July 2026 alongside consultation CP26/2", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:rule.confirmation-of-payee-gives-the-payer-four-outcomes", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "uk-fps:src.psr-specific-direction-20-july-2024", "id": "src.psr-specific-direction-20-july-2024", "rail": "uk-fps", "class": "RuleSource", "name": "PSR Specific Direction 20 (July 2024), FPS APP scam reimbursement requirement", "summary": "The Payment Systems Regulator's direction under section 54 of the Financial Services (Banking Reform) Act 2013 obliging every payment service provider that participates in Faster Payments and provides relevant accounts to reimburse victims of authorised push payment scams, to follow Pay.UK's reimbursement rules, to tell consumers about the right, to change their contract terms, and to register and report. It revoked and replaced the December 2023 version.", "publisher": "Payment Systems Regulator", "url": "https://www.psr.org.uk/media/rqrpnb0w/amended-specific-direction-20-july-2024.pdf", "source_class": "authoritative_primary", "kind": "regulatory_direction", "edition": "July 2024 consolidated version, in force from 12 July 2024", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, fetched and read in full on 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for the uk-fps rail. A RuleSource describes one edition of one document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "July 2024 consolidated version, in force from 12 July 2024", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:exc.app-scam-claim", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:role.directed-psp", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:role.psr", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.app-reimbursement-requirement", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.directed-provider-population-is-wider-than-membership", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.operator-monitors-compliance-and-reports-to-the-regulator", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.providers-must-tell-consumers-and-change-their-terms", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.reimbursement-rules-bind-non-members", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "uk-fps:src.psr-sr1-notice-maximum-excess-value-2023-12", "id": "src.psr-sr1-notice-maximum-excess-value-2023-12", "rail": "uk-fps", "class": "RuleSource", "name": "PSR Specific Requirement 1, notice of maximum excess value, December 2023", "summary": "The regulator's notice fixing the largest excess a sending payment service provider may deduct from one Faster Payments scam claim, and confirming that a provider may apply that figure, a smaller one, or none at all. The notice states that the figure does not move with inflation or any other measure and stays in force until varied or revoked.", "publisher": "Payment Systems Regulator", "url": "https://www.psr.org.uk/media/maslkvyo/sr1-excess-value-supplementary-dec-2023.pdf", "source_class": "authoritative_primary", "kind": "regulatory_notice", "edition": "made 19 December 2023, in force 7 October 2024", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, fetched and read in full on 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for the uk-fps rail. A RuleSource describes one edition of one document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "made 19 December 2023, in force 7 October 2024", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:rule.claim-excess-up-to-100", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "uk-fps:src.psr-sr1-notice-maximum-reimbursement-level-2024-09", "id": "src.psr-sr1-notice-maximum-reimbursement-level-2024-09", "rail": "uk-fps", "class": "RuleSource", "name": "PSR Specific Requirement 1, notice of maximum reimbursement level value, September 2024", "summary": "The regulator's notice fixing the ceiling on what a sending payment service provider must reimburse for one Faster Payments scam claim. The notice states that 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.", "publisher": "Payment Systems Regulator", "url": "https://www.psr.org.uk/media/0w1fmnr5/sr1-max-limit-value-supplementary-sept-2024-publication-version.pdf", "source_class": "authoritative_primary", "kind": "regulatory_notice", "edition": "made 25 September 2024, in force 7 October 2024", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, fetched and read in full on 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for the uk-fps rail. A RuleSource describes one edition of one document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "made 25 September 2024, in force 7 October 2024", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:rule.maximum-level-of-reimbursement", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "uk-fps:src.psrs-2017-part-7", "id": "src.psrs-2017-part-7", "rail": "uk-fps", "class": "RuleSource", "name": "The Payment Services Regulations 2017 (SI 2017/752), Part 7", "summary": "The statutory rights and duties that sit above every UK payment service provider whatever a scheme's rules say: when a payment must reach the payee's provider, when a provider may hold a payment back on suspicion of fraud by someone other than the payer, what a provider owes for an unauthorised payment, who bears a payment sent to a wrong unique identifier, and what happens when a payment is not executed or is executed late.", "publisher": "UK Parliament, published by The National Archives on legislation.gov.uk", "url": "https://www.legislation.gov.uk/uksi/2017/752/part/7", "source_class": "authoritative_primary", "kind": "statute", "edition": "current consolidated text as read 2026-09-20, incorporating amendments to 30 October 2024", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, fetched and read in full on 2026-09-20.", "confidence": "high" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for the uk-fps rail. A RuleSource describes one edition of one document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "current consolidated text as read 2026-09-20, incorporating amendments to 30 October 2024", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:rule.execution-by-the-end-of-the-next-business-day", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.fraud-delay-to-the-fourth-business-day", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.reimbursement-overrides-the-wrong-identifier-defence", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.statutory-liability-for-non-execution-or-late-execution", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.statutory-refund-for-an-unauthorised-transaction", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps:rule.wrong-unique-identifier-recovery-duty", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "uk-fps:txn.direct-corporate-access", "id": "txn.direct-corporate-access", "rail": "uk-fps", "class": "TransactionType", "name": "Direct Corporate Access (DCA) payment", "summary": "A payment a corporate submits in a file straight to the central infrastructure, over the Faster Payments variant of the Bacs file transport and through the Direct Corporate Access module at Vocalink. A directly connected participant sponsors the corporate. Pay.UK states that this route is not suitable for a payment service provider submitting payments for its own customers. A separate file input module carries Faster Payments messages directly to the infrastructure but only outbound: it cannot receive.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "sections 5.6, 10.1 and 10.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-pfmi-self-assessment-2025", "section": "2.2.2", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, sections 5.6, 10.1 and 10.2; Pay.UK 2025 PFMI self-assessment, section 2.2.2. Both read 2026-09-20. sec_code is null and directions can only say credit.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date the payment types", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the Direct Corporate Access route over Secure-IP, that it is not suitable for a PSP submitting on behalf of its customers, and that the File Input Module is send only." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:rule.irrevocable-on-submission-to-ci", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.system-value-ceiling-one-million", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:txn.forward-dated-payment", "id": "txn.forward-dated-payment", "rail": "uk-fps", "class": "TransactionType", "name": "Forward Dated Payment (FDP)", "summary": "An asynchronous one-off payment a customer sets up for a later date, usually without being present. The central infrastructure does not warehouse payments, so the sending participant holds it and submits it only on the execution date. How far ahead a payment may be dated, and at what time of day the run goes, are each participant's own commercial choice, though a participant that also submits standing orders is expected to send forward dated payments after that run. The payer may ask for one to be cancelled before it is submitted, and the participant must retry where funds were short.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "section 5.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-pfmi-self-assessment-2025", "section": "2.2.2", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, section 5.3; Pay.UK 2025 PFMI self-assessment, section 2.2.2. Both read 2026-09-20. sec_code is null and directions can only say credit.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date the payment types", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that no payment is warehoused and the forward dated payment is submitted only on its execution date, with competitive dating limits and retry on insufficient funds." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:rule.irrevocable-on-submission-to-ci", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.retry-later-the-same-day-on-insufficient-funds", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.system-value-ceiling-one-million", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:txn.return-payment", "id": "txn.return-payment", "rail": "uk-fps", "class": "TransactionType", "name": "Return Payment", "summary": "Money going back after a payment was accepted and then could not be applied, for example because it turned out to be fraudulent or failed a money laundering check. It is not a reversal of the original payment and not a debit: it is a fresh credit push that references the original payment, carries a return reason, and should where possible go over Faster Payments. It must be sent within one to three working days of the original payment, depending on the answer the receiving participant gave. Where a transaction limit stops the whole amount going back, the returning institution has to agree another way with the originating institution.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "section 5.4; Required Elements, Returns", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-certainty-of-fate-rule-clarification-2026-01", "section": "annex, rule 10.1", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, section 5.4 and the Returns row of the Required Elements table; Certainty of Fate annex, rule 10.1. Both read 2026-09-20. directions says credit because a return here is a new push in the opposite direction, not a debit of the original payer.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date the payment types", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the Return Payment as a fresh credit push referencing the original within one to three working days." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:rule.return-blocked-by-a-transaction-limit-must-be-agreed", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.return-payment-is-a-new-payment", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.return-payment-within-1-to-3-working-days", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:txn.faster-payment", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:txn.scheme-return-payment", "id": "txn.scheme-return-payment", "rail": "uk-fps", "class": "TransactionType", "name": "Scheme Return Payment", "summary": "A return only the central infrastructure can send. It puts back 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. A participant cannot send one.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "section 5.5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, section 5.5, read 2026-09-20. sec_code is null and directions can only say credit.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date the payment types", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that only the central infrastructure sends a Scheme Return Payment, for a rejected asynchronous payment." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:rule.scheme-return-sent-only-by-the-infrastructure", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:txn.single-immediate-payment", "id": "txn.single-immediate-payment", "rail": "uk-fps", "class": "TransactionType", "name": "Single Immediate Payment (SIP)", "summary": "A synchronous payment made while the payer is present, from internet, mobile, telephone or open banking channels, where the payer wants the money to move at once. The receiving participant answers through the central infrastructure within seconds and the sending participant must tell an attending payer the fate of the payment within 15 seconds. A sending participant may submit one at any hour of any day, including weekends and bank holidays. A small share may be held for fraud or money laundering investigation before submission.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "section 5.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-pfmi-self-assessment-2025", "section": "2.2.2", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, section 5.1; Pay.UK 2025 PFMI self-assessment, section 2.2.2. Both read 2026-09-20. sec_code is null: Faster Payments has no entry class code, and directions can only say credit because every FPS payment type is a credit push.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date the payment types", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the synchronous attended nature of a single immediate payment, the 15 second fate window, and 24 hour submission." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:rule.attended-payer-told-fate-within-15-seconds", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.irrevocable-on-submission-to-ci", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.near-real-time-guideline-10-and-15-seconds", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.system-value-ceiling-one-million", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:txn.faster-payment", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps:txn.standing-order-payment", "id": "txn.standing-order-payment", "rail": "uk-fps", "class": "TransactionType", "name": "Standing Order Payment (SOP)", "summary": "An asynchronous regular payment of a set amount to a named payee, held by the sending participant until the day it is due and only then submitted to the central infrastructure. Standing orders run on weekdays only, excluding public holidays in England and Wales, and a due date falling on a weekend or such a holiday is held to the next working day. A sending participant must submit at least nine in ten of its standing orders between midnight and 06:00, and must retry later in the day where the payer had insufficient funds. The payer may ask for one to be cancelled before it is submitted.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "uk-fps:src.payuk-fps-system-principles-v11", "section": "section 5.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps:src.payuk-pfmi-self-assessment-2025", "section": "2.2.2", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, section 5.2; Pay.UK 2025 PFMI self-assessment, section 2.2.2. Both read 2026-09-20. sec_code is null and directions can only say credit.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date the payment types", "effective_to": null, "effective_note": "Drafted 2026-09-20 from Pay.UK's public documents. The FPS Rules and the FPS Procedures themselves are available only to participants, so when this provision first applied is [Unverified]; the date given is the edition of the public document that describes it.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), Pay.UK's 2025 PFMI self-assessment (published November 2025) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), all read 2026-09-20. The controlling FPS Rules, Procedures and Functional Specification were not read: Pay.UK makes them available to participants only.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the standing order's weekday only execution, 90 percent before 06:00 target, same day retry, and cancellation before submission." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:mandate.standing-order-instruction", "type": "authorises", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.irrevocable-on-submission-to-ci", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.retry-later-the-same-day-on-insufficient-funds", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.standing-orders-90-percent-before-06-00", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.standing-orders-weekdays-only", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.system-value-ceiling-one-million", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "uk-fps:rule.execution-by-the-end-of-the-next-business-day", "uk-fps:rule.fraud-delay-to-the-fourth-business-day", "uk-fps:rule.reimbursement-overrides-the-wrong-identifier-defence", "uk-fps:rule.providers-must-tell-consumers-and-change-their-terms", "uk-fps:rule.other-legal-regimes-are-not-displaced" ], "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.", "relations": [ { "type": "see_also", "to": "uk-fps:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:decision-points", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "uk-fps:src.psrs-2017-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": "uk-fps:src.psr-specific-direction-20-july-2024", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:consumer-law", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:decision-points", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:liability", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:refund", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "uk-fps:rule.receiving-institution-decides-in-seconds", "uk-fps:rule.fraud-and-money-laundering-holds-are-each-providers-own", "uk-fps:rule.confirmation-of-payee-gives-the-payer-four-outcomes", "uk-fps:rule.sending-provider-judges-the-scam-claim", "uk-fps:rule.receiving-provider-chooses-what-to-volunteer-and-when-to-repatriate", "uk-fps:rule.cass-redirection-happens-inside-the-infrastructure" ], "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.", "relations": [ { "type": "see_also", "to": "uk-fps:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:hours", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:consumer-law", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "au-npp:decision-points", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:consumer-law", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:hours", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:liability", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:messages", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:participants", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "uk-fps:rule.irrevocable-on-submission-to-ci", "uk-fps:rule.no-revocation-messaging", "uk-fps:rule.net-settlement-final-at-rtgs-timestamp", "uk-fps:rule.designated-for-settlement-finality", "uk-fps:rule.reimbursement-does-not-affect-finality" ], "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.", "relations": [ { "type": "see_also", "to": "rtp:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "fednow:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "ch-sic-ip:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "uk-fps:src.payuk-pfmi-self-assessment-2025", "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": "uk-fps:src.payuk-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:finality", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:liability", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:recall", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:settlement", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "uk-fps:rule.clearing-24-7", "uk-fps:rule.attended-payer-told-fate-within-15-seconds", "uk-fps:rule.near-real-time-guideline-10-and-15-seconds", "uk-fps:rule.standing-orders-weekdays-only", "uk-fps:rule.standing-orders-90-percent-before-06-00", "uk-fps:rule.retry-later-the-same-day-on-insufficient-funds" ], "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.", "relations": [ { "type": "see_also", "to": "uk-fps:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:decision-points", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "uk-fps:src.payuk-fps-system-principles-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": "uk-fps:src.payuk-certainty-of-fate-rule-clarification-2026-01", "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." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:hours", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:decision-points", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:messages", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "uk-fps:rule.app-reimbursement-requirement", "uk-fps:rule.uk-to-uk-scope-of-the-reimbursement-requirement", "uk-fps:rule.consumer-standard-of-caution-exception", "uk-fps:rule.other-grounds-a-claim-is-not-reimbursable", "uk-fps:rule.thirteen-month-reporting-limit", "uk-fps:rule.notify-the-receiving-provider-within-two-business-hours", "uk-fps:rule.receiving-provider-may-respond-within-three-business-days", "uk-fps:rule.reimburse-within-five-business-days", "uk-fps:rule.stop-the-clock-grounds", "uk-fps:rule.receiving-provider-answers-an-information-request-by-the-25th-business-day", "uk-fps:rule.claim-decided-and-closed-by-the-35th-business-day", "uk-fps:rule.outcome-must-be-told-to-the-consumer-in-writing", "uk-fps:rule.maximum-level-of-reimbursement", "uk-fps:rule.claim-excess-up-to-100", "uk-fps:rule.no-excess-for-a-vulnerable-consumer", "uk-fps:rule.reimbursable-contribution-is-half-apportioned", "uk-fps:rule.contribution-paid-within-five-business-days", "uk-fps:rule.voluntary-reimbursement-is-outside-the-regime", "uk-fps:rule.repatriation-apportionment", "uk-fps:rule.repatriation-within-three-business-days-of-concluding-investigations", "uk-fps:rule.reimbursement-rules-bind-non-members", "uk-fps:rule.schedule-4-is-a-scheme-rule-the-regulator-enforces", "uk-fps:rule.operator-monitors-compliance-and-reports-to-the-regulator" ], "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.", "relations": [ { "type": "see_also", "to": "us-ach:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct-inst:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:consumer-law", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:decision-points", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "uk-fps:src.payuk-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:liability", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:consumer-law", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:decision-points", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:finality", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:limits", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:participants", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:recall", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:refund", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "uk-fps:rule.system-value-ceiling-one-million", "uk-fps:rule.participants-set-their-own-lower-limits", "uk-fps:rule.return-blocked-by-a-transaction-limit-must-be-agreed" ], "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.", "relations": [ { "type": "see_also", "to": "rtp:limits", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "fednow:limits", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "nct-inst:limits", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "au-npp:limits", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "uk-fps:rule.iso-8583-not-iso-20022", "uk-fps:rule.three-response-outcomes", "uk-fps:rule.qualifier-codes-signal-five-timescales", "uk-fps:rule.rejection-and-return-code-lists-are-not-published", "uk-fps:rule.reference-and-remittance-fields", "uk-fps:rule.payment-originating-overseas-carries-a-bic-in-tag-42", "uk-fps:rule.sort-code-directory-must-be-refreshed-weekly" ], "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.", "relations": [ { "type": "see_also", "to": "uk-fps:decision-points", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:hours", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps-reject:rail.uk-fps-reject", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps-return:rail.uk-fps-return", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "au-npp:messages", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:decision-points", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:hours", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:return", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:rail.uk-fps-reject", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "uk-fps:rule.dcsp-eligibility", "uk-fps:rule.dcnsp-and-indirect-access", "uk-fps:rule.onboarding-takes-9-to-12-months", "uk-fps:rule.who-participates-today", "uk-fps:rule.directed-provider-population-is-wider-than-membership" ], "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.", "relations": [ { "type": "see_also", "to": "uk-fps:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:decision-points", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "uk-fps:src.payuk-fps-system-principles-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": "uk-fps:src.payuk-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": "uk-fps:src.payuk-fps-participant-list-page", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms 47 organisations listed as participants today, counted on 2026-09-20." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:participants", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:settlement", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "uk-fps:rule.no-recall-and-no-cancellation-once-submitted", "uk-fps:rule.credit-payment-recovery-is-not-a-reversal", "uk-fps:rule.bank-error-recovery-for-payments-sent-in-bulk-by-mistake" ], "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.", "relations": [ { "type": "see_also", "to": "rtp:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sct:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "au-npp:recall", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:finality", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:refund", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:return", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "uk-fps:rule.statutory-refund-for-an-unauthorised-transaction", "uk-fps:rule.statutory-liability-for-non-execution-or-late-execution", "uk-fps:rule.wrong-unique-identifier-recovery-duty" ], "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.", "relations": [ { "type": "see_also", "to": "pix:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "sepa-sdd-core:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:consumer-law", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "uk-fps:src.psrs-2017-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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:refund", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:consumer-law", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:liability", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:recall", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:return", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "uk-fps:rule.return-payment-is-a-new-payment", "uk-fps:rule.return-payment-within-1-to-3-working-days", "uk-fps-return:rule.return-reason-required", "uk-fps:rule.partial-return-needs-the-originators-agreement", "uk-fps:rule.scheme-return-sent-only-by-the-infrastructure" ], "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.", "relations": [ { "type": "see_also", "to": "rtp:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps-return:rail.uk-fps-return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "uk-fps:src.payuk-fps-system-principles-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": "uk-fps:src.payuk-certainty-of-fate-rule-clarification-2026-01", "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." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:return", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:limits", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:messages", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:recall", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:rule.reject-means-the-payment-never-reaches-the-payee", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:rail.uk-fps-return", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "uk-fps:rule.deferred-net-settlement-three-times-each-working-day", "uk-fps:rule.settlement-in-central-bank-money-at-boe", "uk-fps:rule.net-sender-cap-set-by-each-participant", "uk-fps:rule.pre-funded-account-equal-to-net-sender-cap", "uk-fps:rule.dcnsp-settles-through-its-sponsor" ], "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.", "relations": [ { "type": "see_also", "to": "ca-acss:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "ph-pesonet:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "rtp:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:participants", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "uk-fps:src.payuk-pfmi-self-assessment-2025", "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": "uk-fps:src.payuk-fps-system-principles-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." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:settlement", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:finality", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:hours", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:participants", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps-reject:rail.uk-fps-reject", "id": "rail.uk-fps-reject", "class": "Rail", "rail": "uk-fps-reject", "name": "Faster Payments Rejection Codes", "governing_authority": "Pay.UK Limited", "country": "GB", "currency": "GBP", "operators": [ "Pay.UK Limited", "Vocalink Limited (central infrastructure, under outsourcing from Pay.UK)" ], "record_label": "Reject Reasons", "brief": "docs/rails/uk-fps.md", "scheme": "uk-fps:rail.uk-fps", "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" ], "relations": [ { "type": "sourced_from", "to": "uk-fps-reject:src.payuk-certainty-of-fate-rule-clarification-2026-01", "section": "annex, rules 6.2 and 10.1", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:rail.uk-fps", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "source_class": null, "effective_status_reason": null, "used_by": [ { "from": "uk-fps:rail.uk-fps", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.rejection-and-return-code-lists-are-not-published", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:messages", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps-reject:exc.rejection", "id": "exc.rejection", "rail": "uk-fps-reject", "class": "Exception", "name": "Rejection", "summary": "The receiving institution answers a payment with a rejection instead of an acceptance, carrying a rejection code. The payment does not reach the payee and no money moves. It is one of three answers a receiving institution may give, and it is not the same as a return, which sends money back after a payment was accepted.", "money_moves": false, "outcome": "No money reaches the payee. The rejection code goes back through the central infrastructure to the sending institution, which must tell its customer the fate of the payment.", "relations": [ { "type": "initiated_by", "to": "uk-fps-reject:role.receiving-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "uk-fps-reject:role.receiving-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-reject:rule.rejection-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-reject:rule.reject-means-the-payment-never-reaches-the-payee", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps:rule.rejection-and-return-code-lists-are-not-published", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps-reject:src.payuk-fps-system-principles-v11", "section": "Required Elements, Availability of Funds to the Beneficiary, Fate of Payment", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps-reject:src.payuk-certainty-of-fate-rule-clarification-2026-01", "section": "annex, rules 6.2 and 10.1", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:exc.rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, the Availability of Funds to the Beneficiary and Fate of Payment rows of the Required Elements table; Pay.UK's Certainty of Fate proposed rule clarification, annex rules 6.2 and 10.1. Both read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date the exception path", "effective_to": null, "effective_note": "Drafted 2026-09-20. Pay.UK does not publish the FPS Procedures, Appendix B, FPS Codes, where the code list lives, so when this provision or this code first applied is [Unverified]; the dates given are the editions of the public documents read.", "source_edition": "Faster Payments System Principles v11 (2 January 2026) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), both read 2026-09-20.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps-reject:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms rejection as one of three responses and that no money reaches the payee." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:exc.rejection", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:rule.respond-within-a-few-seconds", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:1114", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-reject:1160", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-reject:1162", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-reject:1163", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-reject:1164", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-reject:1165", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-reject:1170", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-reject:1171", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "uk-fps-reject:role.faster-payments-operator", "id": "role.faster-payments-operator", "rail": "uk-fps-reject", "class": "Role", "name": "Pay.UK Limited, the Faster Payments Operator", "summary": "The company that writes the FPS Rules and the FPS Procedures, and therefore owns the rejection code list. It does not publish the Procedures, and says its rules and procedures are available for review by participants' legal departments.", "kind": "operator", "relations": [ { "type": "sourced_from", "to": "uk-fps-reject:src.payuk-pfmi-self-assessment-2025", "section": "key consideration 23.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:role.faster-payments-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Pay.UK 2025 PFMI self-assessment, key consideration 23.1, read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date the participation framework", "effective_to": null, "effective_note": "Drafted 2026-09-20. Pay.UK does not publish the FPS Procedures, Appendix B, FPS Codes, where the code list lives, so when this provision or this code first applied is [Unverified]; the dates given are the editions of the public documents read.", "source_edition": "Faster Payments System Principles v11 (2 January 2026) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), both read 2026-09-20.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps-reject:src.payuk-pfmi-self-assessment-2025", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that Pay.UK writes the FPS Rules and Procedures and makes them available for review by participants' legal departments rather than publishing them." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps-reject:role.fps-central-infrastructure", "id": "role.fps-central-infrastructure", "rail": "uk-fps-reject", "class": "Role", "name": "FPS central infrastructure", "summary": "The system Vocalink runs for Pay.UK. It carries the payment and the answer between participants, rejects a payment above the system value ceiling of its own motion, and passes participant rejection codes back to the sending institution. LHV's documentation records one stated exception, the duplicate payment identifier code for standing orders, which the infrastructure handles itself and does not pass on.", "kind": "operator", "relations": [ { "type": "sourced_from", "to": "uk-fps-reject:src.payuk-fps-system-principles-v11", "section": "Required Elements, Limits (Individual Payment Amount)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps-reject:src.lhv-connect-payment-reject-codes", "section": "Faster Payment Reject Codes table, the 1181 row", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:role.central-infrastructure-provider", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, the Limits row of the Required Elements table; LHV Connect payment reject codes page, the note carried on code 1181. Both read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date the participation framework", "effective_to": null, "effective_note": "Drafted 2026-09-20. Pay.UK does not publish the FPS Procedures, Appendix B, FPS Codes, where the code list lives, so when this provision or this code first applied is [Unverified]; the dates given are the editions of the public documents read.", "source_edition": "Faster Payments System Principles v11 (2 January 2026) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), both read 2026-09-20.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps-reject:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that the central infrastructure rejects a payment above the system value ceiling of its own motion." }, { "source": "uk-fps-reject:src.lhv-connect-payment-reject-codes", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that the central infrastructure passes all participant rejection codes through to the sending institution except code 1181, duplicate FPID for standing orders, which it processes itself." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps-reject:role.receiving-fps-institution", "id": "role.receiving-fps-institution", "rail": "uk-fps-reject", "class": "Role", "name": "Receiving FPS Institution", "summary": "The participant that receives a payment from the central infrastructure and answers it. It must respond within a few seconds with an unqualified acceptance, a qualified acceptance carrying a qualifier code, or a rejection carrying a rejection code, and it must specify the rejection code if it rejects. Every code drafted in this directory is read as one this participant sends.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "uk-fps-reject:src.payuk-fps-system-principles-v11", "section": "Required Elements, Availability of Funds to the Beneficiary", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps-reject:src.payuk-certainty-of-fate-rule-clarification-2026-01", "section": "annex, rules 6.2 and 10.1", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:role.receiving-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, the Availability of Funds to the Beneficiary row of the Required Elements table; Pay.UK's Certainty of Fate proposed rule clarification, annex rules 6.2 and 10.1. Both read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date the participation framework", "effective_to": null, "effective_note": "Drafted 2026-09-20. Pay.UK does not publish the FPS Procedures, Appendix B, FPS Codes, where the code list lives, so when this provision or this code first applied is [Unverified]; the dates given are the editions of the public documents read.", "source_edition": "Faster Payments System Principles v11 (2 January 2026) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), both read 2026-09-20.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps-reject:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the receiving institution's duty to respond within seconds with one of three outcomes and to specify the rejection code." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps-reject:exc.rejection", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:exc.rejection", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:rule.reject-means-the-payment-never-reaches-the-payee", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:rule.rejection-code-required", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:rule.respond-within-a-few-seconds", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:1114", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-reject:1160", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-reject:1162", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-reject:1163", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-reject:1164", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-reject:1165", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-reject:1170", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-reject:1171", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "uk-fps-reject:role.sending-fps-institution", "id": "role.sending-fps-institution", "rail": "uk-fps-reject", "class": "Role", "name": "Sending FPS Institution", "summary": "The participant that submitted the payment. It receives the rejection code back through the central infrastructure and must tell its customer the fate of the payment. Pay.UK's proposed clarification would require it to make the standard code information accessible to authorised agents of its customers, such as payment initiation service providers, in near real time.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "uk-fps-reject:src.payuk-fps-system-principles-v11", "section": "Required Elements, Fate of Payment", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps-reject:src.payuk-certainty-of-fate-rule-clarification-2026-01", "section": "annex, rule 9.3.1", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:role.sending-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, the Fate of Payment row of the Required Elements table; Certainty of Fate annex, rule 9.3.1. Both read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date the participation framework", "effective_to": null, "effective_note": "Drafted 2026-09-20. Pay.UK does not publish the FPS Procedures, Appendix B, FPS Codes, where the code list lives, so when this provision or this code first applied is [Unverified]; the dates given are the editions of the public documents read.", "source_edition": "Faster Payments System Principles v11 (2 January 2026) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), both read 2026-09-20.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps-reject:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the sending institution's duty to tell its customer the fate of the payment." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps-reject:rule.reject-means-the-payment-never-reaches-the-payee", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps-reject:rule.reject-means-the-payment-never-reaches-the-payee", "id": "rule.reject-means-the-payment-never-reaches-the-payee", "rail": "uk-fps-reject", "class": "Rule", "name": "A rejected payment never reaches the payee, so there is nothing to undo", "statement": "A rejection is an answer to a payment, not a way of sending money back. The payee is never credited, so no reversal, return or recovery is needed and none is possible. That is the difference between a rejection code and a return reason on this rail: a return moves money back after the payment was accepted, and this does not. The sending institution must still tell its customer what happened.", "rests_on": "rule", "relations": [ { "type": "binds", "to": "uk-fps-reject:role.receiving-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps-reject:role.sending-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps-reject:src.payuk-fps-system-principles-v11", "section": "Required Elements, Availability of Funds to the Beneficiary, Fate of Payment, Returns", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, the Availability of Funds to the Beneficiary, Fate of Payment and Returns rows of the Required Elements table, read 2026-09-20. That a rejected payment needs no return is Orca's reading of the distinction Pay.UK draws between a rejection and a Return Payment [Inference].", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20. Pay.UK does not publish the FPS Procedures, Appendix B, FPS Codes, where the code list lives, so when this provision or this code first applied is [Unverified]; the dates given are the editions of the public documents read.", "source_edition": "Faster Payments System Principles v11 (2 January 2026) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), both read 2026-09-20.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps-reject:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that a rejection answers a payment before the payee is credited, distinct from a Return Payment which moves money back after acceptance." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps-reject:exc.rejection", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:1114", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:1160", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:1162", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:1163", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:1164", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:1165", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:1170", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:1171", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps-reject:rule.rejection-code-required", "id": "rule.rejection-code-required", "rail": "uk-fps-reject", "class": "Rule", "name": "A rejection must carry a rejection code", "statement": "A receiving institution that rejects a payment must specify the rejection code in its response. Where it can accept without qualification the infrastructure indicates code 0000, accepted without qualification; where it cannot update the account in near real time it must instead convey clear standardised information about the fate of the payment using the codes in the FPS Procedures, Appendix B, FPS Codes, at section 7 for qualifier codes or section 8.2 for institution rejection codes.", "rests_on": "rule", "relations": [ { "type": "binds", "to": "uk-fps-reject:role.receiving-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps-reject:src.payuk-certainty-of-fate-rule-clarification-2026-01", "section": "annex, rules 6.2a, 6.2b and 10.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:rule.rejection-and-return-code-lists-are-not-published", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Pay.UK's Certainty of Fate proposed rule clarification v1.0, annex rules 6.2 and 10.1, read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20. Pay.UK does not publish the FPS Procedures, Appendix B, FPS Codes, where the code list lives, so when this provision or this code first applied is [Unverified]; the dates given are the editions of the public documents read.", "source_edition": "Faster Payments System Principles v11 (2 January 2026) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), both read 2026-09-20.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps-reject:src.payuk-certainty-of-fate-rule-clarification-2026-01", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that a rejecting institution must specify the rejection code, that code 0000 signals accepted without qualification, and that otherwise the codes come from FPS Procedures Appendix B sections 7 and 8.2." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps-reject:exc.rejection", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:1114", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:1160", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:1162", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:1163", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:1164", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:1165", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:1170", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:1171", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps-reject:rule.respond-within-a-few-seconds", "id": "rule.respond-within-a-few-seconds", "rail": "uk-fps-reject", "class": "Rule", "name": "The receiving institution must answer within a few seconds", "statement": "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.", "rests_on": "rule", "relations": [ { "type": "part_of", "to": "uk-fps-reject:exc.rejection", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps-reject:role.receiving-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps-reject:src.payuk-fps-system-principles-v11", "section": "Required Elements, Availability of Funds to the Beneficiary; section 5.1", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:rule.three-response-outcomes", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, section 5.1 and the Availability of Funds to the Beneficiary row of the Required Elements table, read 2026-09-20. No typed time window is carried: Orca Core v0 has no unit below an hour, and the figure itself is not public.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20. Pay.UK does not publish the FPS Procedures, Appendix B, FPS Codes, where the code list lives, so when this provision or this code first applied is [Unverified]; the dates given are the editions of the public documents read.", "source_edition": "Faster Payments System Principles v11 (2 January 2026) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), both read 2026-09-20.", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "primary_not_public": true, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "uk-fps-reject:1114", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:1160", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:1162", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:1163", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:1164", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:1165", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:1170", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:1171", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps-reject:src.lhv-connect-payment-reject-codes", "id": "src.lhv-connect-payment-reject-codes", "rail": "uk-fps-reject", "class": "RuleSource", "name": "LHV Connect documentation, Payment Reject Codes", "summary": "A developer reference table from LHV, a Faster Payments direct participant, listing 50 numeric Faster Payments reject codes under their own heading, separate from the SEPA instant lists on the same page. The page states that these codes are carried in the transaction level additional information of LHV's own payment status message, which is its API wrapper rather than the scheme message. Source family B for these records.", "publisher": "LHV", "url": "https://docs.lhv.com/home/connect/overview/code-reference-tables/payment-reject-codes", "source_class": "secondary", "kind": "developer_documentation", "edition": "live page as read 2026-09-20; the page states it was last updated about a year earlier", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, fetched and read in full on 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for this rail. A RuleSource describes one edition of one document; its status stays draft and the monthly watch dates it through consulted_on. The same documents are held under uk-fps as well, because a corroboration names a RuleSource in the record's own rail.", "source_edition": "live page as read 2026-09-20; the page states it was last updated about a year earlier", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "uk-fps-reject:role.fps-central-infrastructure", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "uk-fps-reject:src.natwest-faster-payment-reject-and-reason-codes", "id": "src.natwest-faster-payment-reject-and-reason-codes", "rail": "uk-fps-reject", "class": "RuleSource", "name": "NatWest support centre, Understanding Faster Payment Rejection and Reason Codes", "summary": "A consumer-facing page from NatWest, a Faster Payments direct participant, with one table of reject and return reason codes and a plain explanation of each for a customer whose payment failed. It names 17 rejection codes individually, treats three of them as one entry, and collapses everything else into a single technical failure row. Source family A for these records; it corroborates only the codes it names on their own.", "publisher": "NatWest", "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", "kind": "bank_support_page", "edition": "live page as read 2026-09-20; the page carries no date", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, fetched and read in full on 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for this rail. A RuleSource describes one edition of one document; its status stays draft and the monthly watch dates it through consulted_on. The same documents are held under uk-fps as well, because a corroboration names a RuleSource in the record's own rail.", "source_edition": "live page as read 2026-09-20; the page carries no date", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps-reject:src.payuk-certainty-of-fate-rule-clarification-2026-01", "id": "src.payuk-certainty-of-fate-rule-clarification-2026-01", "rail": "uk-fps-reject", "class": "RuleSource", "name": "Pay.UK's work on Certainty of Fate to support A2A retail transactions: proposed rule clarification, v1.0", "summary": "The only public Pay.UK document read that names where the Faster Payments code lists live: the FPS Procedures, Appendix B, FPS Codes, with qualifier codes at section 7 and institution rejection codes at section 8.2. Its annex prints the current wording of the rules on beneficiary accounts, the fate of a single immediate payment and the receiving institution's general obligations, with January 2026 proposals marked in bold.", "publisher": "Pay.UK Limited", "url": "https://www.wearepay.uk/wp-content/uploads/2026/01/Pay.UK-CoF-Proposed-Rule-Clarification-January-2026.pdf", "source_class": "public_primary", "kind": "consultation_paper", "edition": "v1.0, January 2026", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, fetched and read in full on 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for this rail. A RuleSource describes one edition of one document; its status stays draft and the monthly watch dates it through consulted_on. The same documents are held under uk-fps as well, because a corroboration names a RuleSource in the record's own rail.", "source_edition": "v1.0, January 2026", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "uk-fps-reject:rail.uk-fps-reject", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:exc.rejection", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:role.receiving-fps-institution", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:role.sending-fps-institution", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:rule.rejection-code-required", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "uk-fps-reject:src.payuk-fps-system-principles-v11", "id": "src.payuk-fps-system-principles-v11", "rail": "uk-fps-reject", "class": "RuleSource", "name": "Faster Payments System Principles, FPS information guide, v11", "summary": "Pay.UK's public guide to the rail. For rejections it gives the three answers a receiving institution may make, the requirement to answer within a few seconds, the duty on the sending institution to tell its customer the fate of the payment, the error checking guidelines behind an unqualified acceptance, and the system value ceiling the central infrastructure itself enforces. Section 1.4 says it is not a controlling specification.", "publisher": "Pay.UK Limited", "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", "kind": "information_guide", "edition": "v11, 2 January 2026", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, fetched and read in full on 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for this rail. A RuleSource describes one edition of one document; its status stays draft and the monthly watch dates it through consulted_on. The same documents are held under uk-fps as well, because a corroboration names a RuleSource in the record's own rail.", "source_edition": "v11, 2 January 2026", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "uk-fps-reject:exc.rejection", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-reject:role.fps-central-infrastructure", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-reject:role.receiving-fps-institution", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-reject:role.sending-fps-institution", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-reject:rule.reject-means-the-payment-never-reaches-the-payee", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-reject:rule.respond-within-a-few-seconds", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:txn.faster-payment", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "uk-fps-reject:src.payuk-pfmi-self-assessment-2025", "id": "src.payuk-pfmi-self-assessment-2025", "rail": "uk-fps-reject", "class": "RuleSource", "name": "2025 PFMI self-assessment of Pay.UK", "summary": "Pay.UK's assessment against the CPMI-IOSCO Principles for Financial Market Infrastructures. Key consideration 23.1 is the statement that the FPS rules and procedures are available for review by participants' legal departments and that the website carries only the list of system documentation, which is why every code record here is marked as resting on sources other than the operator's own text.", "publisher": "Pay.UK Limited", "url": "https://www.wearepay.uk/wp-content/uploads/2025/11/2025-PFMI-self-assessment-of-Pay.UK_.pdf", "source_class": "public_primary", "kind": "regulatory_self_assessment", "edition": "position as at end of August 2025, published November 2025", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, fetched and read in full on 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for this rail. A RuleSource describes one edition of one document; its status stays draft and the monthly watch dates it through consulted_on. The same documents are held under uk-fps as well, because a corroboration names a RuleSource in the record's own rail.", "source_edition": "position as at end of August 2025, published November 2025", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "uk-fps-reject:role.faster-payments-operator", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "uk-fps-reject:txn.faster-payment", "id": "txn.faster-payment", "rail": "uk-fps-reject", "class": "TransactionType", "name": "Faster Payment", "summary": "A sterling credit push over the Faster Payment System. Every Faster Payments payment type is a credit push, so a rejection concerns money that was going to a payee and does not move. The code lists make no distinction between the payment types in any public source read.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "uk-fps-reject:src.payuk-fps-system-principles-v11", "section": "section 5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:txn.single-immediate-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, section 5, read 2026-09-20. sec_code is null: Faster Payments has no entry class code, and directions can only say credit.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date the payment types", "effective_to": null, "effective_note": "Drafted 2026-09-20. Pay.UK does not publish the FPS Procedures, Appendix B, FPS Codes, where the code list lives, so when this provision or this code first applied is [Unverified]; the dates given are the editions of the public documents read.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), read 2026-09-20.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps-reject:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that every Faster Payments payment type is a sterling credit push." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps-reject:1114", "id": "1114", "rail": "uk-fps-reject", "class": "ReasonCode", "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, "guidance": "Send a new payment once the details are corrected. Nothing reached the payee and nothing settled, so there is nothing to reverse or return." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "uk-fps-reject:txn.faster-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "uk-fps-reject:exc.rejection", "evidence": [ { "source": "uk-fps-reject:src.lhv-connect-payment-reject-codes" }, { "source": "uk-fps-reject:src.natwest-faster-payment-reject-and-reason-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "uk-fps-reject:role.receiving-fps-institution", "evidence": [ { "source": "uk-fps-reject:src.lhv-connect-payment-reject-codes" } ], "note": "[Inference] LHV's page records that the central infrastructure passes participant rejection codes through to the sending institution, with one stated exception, so a code in this range is read as the receiving institution's rather than the infrastructure's. No public source read says so for this code on its own.", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-reject:rule.respond-within-a-few-seconds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-reject:rule.rejection-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-reject:rule.reject-means-the-payment-never-reaches-the-payee", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps:rule.rejection-and-return-code-lists-are-not-published", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps-reject:1160", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps-reject:1162", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "uk-fps-reject:src.lhv-connect-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": "uk-fps-reject:src.natwest-faster-payment-reject-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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps-reject:1160", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:1162", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps-reject:1160", "id": "1160", "rail": "uk-fps-reject", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "uk-fps-reject:txn.faster-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "uk-fps-reject:exc.rejection", "evidence": [ { "source": "uk-fps-reject:src.lhv-connect-payment-reject-codes" }, { "source": "uk-fps-reject:src.natwest-faster-payment-reject-and-reason-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "uk-fps-reject:role.receiving-fps-institution", "evidence": [ { "source": "uk-fps-reject:src.lhv-connect-payment-reject-codes" } ], "note": "[Inference] LHV's page records that the central infrastructure passes participant rejection codes through to the sending institution, with one stated exception, so a code in this range is read as the receiving institution's rather than the infrastructure's. No public source read says so for this code on its own.", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-reject:rule.respond-within-a-few-seconds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-reject:rule.rejection-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-reject:rule.reject-means-the-payment-never-reaches-the-payee", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps:rule.rejection-and-return-code-lists-are-not-published", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps-reject:1114", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps-reject:1162", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "uk-fps-reject:src.lhv-connect-payment-reject-codes", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms code 1160 as creditor account closed." }, { "source": "uk-fps-reject:src.natwest-faster-payment-reject-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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps-reject:1114", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps-reject:1162", "id": "1162", "rail": "uk-fps-reject", "class": "ReasonCode", "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, "guidance": "Send again once the name is confirmed with the payee. Nothing reached the payee, so there is nothing to return." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "uk-fps-reject:txn.faster-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "uk-fps-reject:exc.rejection", "evidence": [ { "source": "uk-fps-reject:src.lhv-connect-payment-reject-codes" }, { "source": "uk-fps-reject:src.natwest-faster-payment-reject-and-reason-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "uk-fps-reject:role.receiving-fps-institution", "evidence": [ { "source": "uk-fps-reject:src.lhv-connect-payment-reject-codes" } ], "note": "[Inference] LHV's page records that the central infrastructure passes participant rejection codes through to the sending institution, with one stated exception, so a code in this range is read as the receiving institution's rather than the infrastructure's. No public source read says so for this code on its own.", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-reject:rule.respond-within-a-few-seconds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-reject:rule.rejection-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-reject:rule.reject-means-the-payment-never-reaches-the-payee", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps:rule.rejection-and-return-code-lists-are-not-published", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps-reject:1171", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps-reject:1114", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "uk-fps-reject:src.lhv-connect-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": "uk-fps-reject:src.natwest-faster-payment-reject-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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps-reject:1114", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:1160", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-reject:1171", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps-reject:1163", "id": "1163", "rail": "uk-fps-reject", "class": "ReasonCode", "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, "guidance": "Send again with the reference filled in. Nothing reached the payee, so there is nothing to return." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "uk-fps-reject:txn.faster-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "uk-fps-reject:exc.rejection", "evidence": [ { "source": "uk-fps-reject:src.lhv-connect-payment-reject-codes" }, { "source": "uk-fps-reject:src.natwest-faster-payment-reject-and-reason-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "uk-fps-reject:role.receiving-fps-institution", "evidence": [ { "source": "uk-fps-reject:src.lhv-connect-payment-reject-codes" } ], "note": "[Inference] LHV's page records that the central infrastructure passes participant rejection codes through to the sending institution, with one stated exception, so a code in this range is read as the receiving institution's rather than the infrastructure's. No public source read says so for this code on its own.", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-reject:rule.respond-within-a-few-seconds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-reject:rule.rejection-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-reject:rule.reject-means-the-payment-never-reaches-the-payee", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps:rule.rejection-and-return-code-lists-are-not-published", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps-reject:1164", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "uk-fps-reject:src.lhv-connect-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": "uk-fps-reject:src.natwest-faster-payment-reject-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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps-reject:1164", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps-reject:1164", "id": "1164", "rail": "uk-fps-reject", "class": "ReasonCode", "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, "guidance": "Send again with the corrected reference. Nothing reached the payee, so there is nothing to return." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "uk-fps-reject:txn.faster-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "uk-fps-reject:exc.rejection", "evidence": [ { "source": "uk-fps-reject:src.lhv-connect-payment-reject-codes" }, { "source": "uk-fps-reject:src.natwest-faster-payment-reject-and-reason-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "uk-fps-reject:role.receiving-fps-institution", "evidence": [ { "source": "uk-fps-reject:src.lhv-connect-payment-reject-codes" } ], "note": "[Inference] LHV's page records that the central infrastructure passes participant rejection codes through to the sending institution, with one stated exception, so a code in this range is read as the receiving institution's rather than the infrastructure's. No public source read says so for this code on its own.", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-reject:rule.respond-within-a-few-seconds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-reject:rule.rejection-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-reject:rule.reject-means-the-payment-never-reaches-the-payee", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps:rule.rejection-and-return-code-lists-are-not-published", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps-reject:1163", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "uk-fps-reject:src.lhv-connect-payment-reject-codes", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms code 1164 as reference information is incorrect." }, { "source": "uk-fps-reject:src.natwest-faster-payment-reject-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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps-reject:1163", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps-reject:1165", "id": "1165", "rail": "uk-fps-reject", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "uk-fps-reject:txn.faster-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "uk-fps-reject:exc.rejection", "evidence": [ { "source": "uk-fps-reject:src.lhv-connect-payment-reject-codes" }, { "source": "uk-fps-reject:src.natwest-faster-payment-reject-and-reason-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "uk-fps-reject:role.receiving-fps-institution", "evidence": [ { "source": "uk-fps-reject:src.lhv-connect-payment-reject-codes" } ], "note": "[Inference] LHV's page records that the central infrastructure passes participant rejection codes through to the sending institution, with one stated exception, so a code in this range is read as the receiving institution's rather than the infrastructure's. No public source read says so for this code on its own.", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-reject:rule.respond-within-a-few-seconds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-reject:rule.rejection-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-reject:rule.reject-means-the-payment-never-reaches-the-payee", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps:rule.rejection-and-return-code-lists-are-not-published", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps-reject:1170", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "uk-fps-reject:src.lhv-connect-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": "uk-fps-reject:src.natwest-faster-payment-reject-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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps-reject:1170", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps-reject:1170", "id": "1170", "rail": "uk-fps-reject", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "uk-fps-reject:txn.faster-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "uk-fps-reject:exc.rejection", "evidence": [ { "source": "uk-fps-reject:src.lhv-connect-payment-reject-codes" }, { "source": "uk-fps-reject:src.natwest-faster-payment-reject-and-reason-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "uk-fps-reject:role.receiving-fps-institution", "evidence": [ { "source": "uk-fps-reject:src.lhv-connect-payment-reject-codes" } ], "note": "[Inference] LHV's page records that the central infrastructure passes participant rejection codes through to the sending institution, with one stated exception, so a code in this range is read as the receiving institution's rather than the infrastructure's. No public source read says so for this code on its own.", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-reject:rule.respond-within-a-few-seconds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-reject:rule.rejection-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-reject:rule.reject-means-the-payment-never-reaches-the-payee", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps:rule.rejection-and-return-code-lists-are-not-published", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps-reject:1165", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "uk-fps-reject:src.lhv-connect-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": "uk-fps-reject:src.natwest-faster-payment-reject-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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps-reject:1165", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps-reject:1171", "id": "1171", "rail": "uk-fps-reject", "class": "ReasonCode", "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, "guidance": "Send again with the payee's name present. Nothing reached the payee, so there is nothing to return." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "uk-fps-reject:txn.faster-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "uk-fps-reject:exc.rejection", "evidence": [ { "source": "uk-fps-reject:src.lhv-connect-payment-reject-codes" }, { "source": "uk-fps-reject:src.natwest-faster-payment-reject-and-reason-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "uk-fps-reject:role.receiving-fps-institution", "evidence": [ { "source": "uk-fps-reject:src.lhv-connect-payment-reject-codes" } ], "note": "[Inference] LHV's page records that the central infrastructure passes participant rejection codes through to the sending institution, with one stated exception, so a code in this range is read as the receiving institution's rather than the infrastructure's. No public source read says so for this code on its own.", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-reject:rule.respond-within-a-few-seconds", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-reject:rule.rejection-code-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-reject:rule.reject-means-the-payment-never-reaches-the-payee", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps:rule.rejection-and-return-code-lists-are-not-published", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps-reject:1162", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "uk-fps-reject:src.lhv-connect-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": "uk-fps-reject:src.natwest-faster-payment-reject-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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps-reject:1162", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps-return:rail.uk-fps-return", "id": "rail.uk-fps-return", "class": "Rail", "rail": "uk-fps-return", "name": "Faster Payments Return Reasons", "governing_authority": "Pay.UK Limited", "country": "GB", "currency": "GBP", "operators": [ "Pay.UK Limited", "Vocalink Limited (central infrastructure, under outsourcing from Pay.UK)" ], "record_label": "Return Reasons", "brief": "docs/rails/uk-fps.md", "scheme": "uk-fps:rail.uk-fps", "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" ], "relations": [ { "type": "sourced_from", "to": "uk-fps-return:src.payuk-fps-system-principles-v11", "section": "section 5.4", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:rail.uk-fps", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "source_class": null, "effective_status_reason": null, "used_by": [ { "from": "uk-fps:rail.uk-fps", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.rejection-and-return-code-lists-are-not-published", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:messages", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:return", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps-return:exc.return-payment", "id": "exc.return-payment", "rail": "uk-fps-return", "class": "Exception", "name": "Return Payment", "summary": "A payment was accepted and then could not be made available to the payee, so the funds go back as a new credit push that references the original and carries a return reason. The original payment is not reversed and the payee is not debited by the scheme. It must go within one to three working days of the original payment, depending on the answer the receiving participant gave.", "money_moves": true, "outcome": "A fresh credit payment carrying a return reason reaches the original sending institution. The original payment stands.", "relations": [ { "type": "initiated_by", "to": "uk-fps-return:role.receiving-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "uk-fps-return:role.receiving-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-return:rule.return-is-a-new-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-return:rule.return-reason-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps:rule.rejection-and-return-code-lists-are-not-published", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps-return:src.payuk-fps-system-principles-v11", "section": "section 5.4; Required Elements, Returns", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps-return:src.payuk-certainty-of-fate-rule-clarification-2026-01", "section": "annex, rule 10.1", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:exc.return-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, section 5.4 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.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date the exception path", "effective_to": null, "effective_note": "Drafted 2026-09-20. Pay.UK does not publish the FPS Procedures, Appendix B, FPS Codes, where the code list lives, so when this provision or this code first applied is [Unverified]; the dates given are the editions of the public documents read.", "source_edition": "Faster Payments System Principles v11 (2 January 2026) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), both read 2026-09-20.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps-return:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the Return Payment as a new credit push referencing the original within one to three working days." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:exc.return-payment", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.return-payment-within-1-to-3-working-days", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000001", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-return:00000002", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-return:00000005", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-return:00000006", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-return:00000007", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-return:00000008", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-return:00000009", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-return:00000010", "type": "raised_in", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "uk-fps-return:role.faster-payments-operator", "id": "role.faster-payments-operator", "rail": "uk-fps-return", "class": "Role", "name": "Pay.UK Limited, the Faster Payments Operator", "summary": "The company that writes the FPS Rules and the FPS Procedures, and therefore owns the return reason list. It does not publish the Procedures, and says its rules and procedures are available for review by participants' legal departments.", "kind": "operator", "relations": [ { "type": "sourced_from", "to": "uk-fps-return:src.payuk-pfmi-self-assessment-2025", "section": "key consideration 23.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:role.faster-payments-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Pay.UK 2025 PFMI self-assessment, key consideration 23.1, read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date the participation framework", "effective_to": null, "effective_note": "Drafted 2026-09-20. Pay.UK does not publish the FPS Procedures, Appendix B, FPS Codes, where the code list lives, so when this provision or this code first applied is [Unverified]; the dates given are the editions of the public documents read.", "source_edition": "Faster Payments System Principles v11 (2 January 2026) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), both read 2026-09-20.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps-return:src.payuk-pfmi-self-assessment-2025", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that Pay.UK writes the FPS Rules and Procedures and makes them available for review by participants' legal departments rather than publishing them." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps-return:role.receiving-fps-institution", "id": "role.receiving-fps-institution", "rail": "uk-fps-return", "class": "Role", "name": "Receiving FPS Institution", "summary": "The participant that accepted the payment and then could not make the funds available to the payee. It raises the Return Payment, a fresh credit push referencing the original, specifies the return reason, and must send it over Faster Payments where it can and within one to three working days of the original payment. Every reason drafted in this directory is read as one this participant sends.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "uk-fps-return:src.payuk-fps-system-principles-v11", "section": "section 5.4; Required Elements, Returns", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps-return:src.payuk-certainty-of-fate-rule-clarification-2026-01", "section": "annex, rule 10.1", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:role.receiving-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, section 5.4 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.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date the participation framework", "effective_to": null, "effective_note": "Drafted 2026-09-20. Pay.UK does not publish the FPS Procedures, Appendix B, FPS Codes, where the code list lives, so when this provision or this code first applied is [Unverified]; the dates given are the editions of the public documents read.", "source_edition": "Faster Payments System Principles v11 (2 January 2026) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), both read 2026-09-20.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps-return:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that the receiving institution raises the Return Payment, specifies the return reason, and sends it within one to three working days." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:rule.return-payment-within-1-to-3-working-days", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:exc.return-payment", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:exc.return-payment", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:rule.return-is-a-new-payment", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:rule.return-reason-required", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000001", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-return:00000002", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-return:00000005", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-return:00000006", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-return:00000007", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-return:00000008", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-return:00000009", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-return:00000010", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "uk-fps-return:role.sending-fps-institution", "id": "role.sending-fps-institution", "rail": "uk-fps-return", "class": "Role", "name": "Sending FPS Institution", "summary": "The participant that sent the original payment and receives the returned funds. Where a return cannot be made as a Return Payment, for instance because it is partial, it is this participant, as initiator of the original payment, whose agreement is needed before the money comes back as a new payment quoting the original payment identifier.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "uk-fps-return:src.payuk-certainty-of-fate-rule-clarification-2026-01", "section": "annex, rule 10.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:role.sending-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Pay.UK's Certainty of Fate proposed rule clarification, annex rule 10.1, read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date the participation framework", "effective_to": null, "effective_note": "Drafted 2026-09-20. Pay.UK does not publish the FPS Procedures, Appendix B, FPS Codes, where the code list lives, so when this provision or this code first applied is [Unverified]; the dates given are the editions of the public documents read.", "source_edition": "Faster Payments System Principles v11 (2 January 2026) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), both read 2026-09-20.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps-return:src.payuk-certainty-of-fate-rule-clarification-2026-01", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that the initiator of the original payment must agree before a partial return comes back as a new payment quoting the original payment identifier." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps-return:rule.return-is-a-new-payment", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps-return:rule.return-is-a-new-payment", "id": "rule.return-is-a-new-payment", "rail": "uk-fps-return", "class": "Rule", "name": "A return is a new payment, not a reversal", "statement": "The money goes back as a fresh credit push that references the original payment, sent over Faster Payments where possible. Nothing is reversed and nothing is debited from the payee by the scheme. Where transaction limits stop the whole amount going back as one Return Payment, the returning institution must contact the originating institution and agree how the funds are to be returned; and where the return is partial, or a Return Payment cannot be built at all, it must be made as a new payment with the agreement of the initiator of the original payment, quoting the first 18 characters of the original payment identifier in the reference field.", "rests_on": "rule", "relations": [ { "type": "binds", "to": "uk-fps-return:role.receiving-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps-return:role.sending-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps-return:src.payuk-fps-system-principles-v11", "section": "section 5.4; Required Elements, Returns", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps-return:src.payuk-certainty-of-fate-rule-clarification-2026-01", "section": "annex, rule 10.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:rule.return-payment-is-a-new-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:rule.return-blocked-by-a-transaction-limit-must-be-agreed", "note": "The transaction limit clause of annex rule 10.1 on its own, in the uk-fps directory, with the addition that the limit neither excuses keeping the money nor permits a partial Return Payment.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, section 5.4 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.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20. Pay.UK does not publish the FPS Procedures, Appendix B, FPS Codes, where the code list lives, so when this provision or this code first applied is [Unverified]; the dates given are the editions of the public documents read.", "source_edition": "Faster Payments System Principles v11 (2 January 2026) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), both read 2026-09-20.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps-return:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms a Return Payment as a new payment referencing the original, sent via Faster Payments where possible." }, { "source": "uk-fps-return:src.payuk-certainty-of-fate-rule-clarification-2026-01", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the transaction limit agreement duty and the New Payment route for a partial return, with the original initiator's agreement and the first 18 characters of the original payment identifier." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps:rule.partial-return-needs-the-originators-agreement", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:rule.return-blocked-by-a-transaction-limit-must-be-agreed", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:exc.return-payment", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000001", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000002", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000005", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000006", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000007", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000008", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000009", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000010", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps-return:rule.return-reason-required", "id": "rule.return-reason-required", "rail": "uk-fps-return", "class": "Rule", "name": "A Return Payment must specify the return reason", "statement": "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.", "rests_on": "rule", "relations": [ { "type": "binds", "to": "uk-fps-return:role.receiving-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "uk-fps-return:src.payuk-certainty-of-fate-rule-clarification-2026-01", "section": "annex, rule 10.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "uk-fps:exc.return-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "uk-fps:role.receiving-fps-institution", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Pay.UK's Certainty of Fate proposed rule clarification v1.0, annex rule 10.1, read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date this provision", "effective_to": null, "effective_note": "Drafted 2026-09-20. Pay.UK does not publish the FPS Procedures, Appendix B, FPS Codes, where the code list lives, so when this provision or this code first applied is [Unverified]; the dates given are the editions of the public documents read. Merged 2026-09-20: uk-fps:rule.return-payment-quotes-a-return-reason stated the same duty from the same source at the same section in the uk-fps directory and was deleted; the uk-fps return fact that listed it now lists this record, and the deleted record's part_of and binds links moved here. Two things the deleted statement carried besides the duty are held elsewhere and are not lost: that Pay.UK does not publish the return reason list, and that 6 of the 14 values a participant's developer documentation lists are held back, are both known gaps on uk-fps-return and both appear in the uk-fps return fact's exceptions. Its sourced_from link was not moved: it named the uk-fps copy of Pay.UK's Certainty of Fate rule clarification, the same document this record already cites at the same section.", "source_edition": "Faster Payments System Principles v11 (2 January 2026) and Pay.UK's Certainty of Fate proposed rule clarification v1.0 (January 2026), both read 2026-09-20.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps-return:src.payuk-certainty-of-fate-rule-clarification-2026-01", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms the duty to specify the return reason on a Return Payment." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps-return:exc.return-payment", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000001", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000002", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000005", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000006", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000007", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000008", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000009", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000010", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps-return:src.lhv-connect-payment-return-codes", "id": "src.lhv-connect-payment-return-codes", "rail": "uk-fps-return", "class": "RuleSource", "name": "LHV Connect documentation, Payment Return Codes", "summary": "A developer reference table from LHV, a Faster Payments direct participant, listing 14 eight digit Faster Payments return codes under their own heading, separate from the group, SEPA and Bacs lists on the same page. The page states that these codes go in the instruction to the debtor agent field of LHV's own payment initiation message, which is its API wrapper rather than the scheme message. Source family B for these records.", "publisher": "LHV", "url": "https://docs.lhv.com/home/connect/overview/code-reference-tables/payment-return-codes", "source_class": "secondary", "kind": "developer_documentation", "edition": "live page as read 2026-09-20; the page states it was last updated about eleven months earlier", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, fetched and read in full on 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for this rail. A RuleSource describes one edition of one document; its status stays draft and the monthly watch dates it through consulted_on. The same documents are held under uk-fps as well, because a corroboration names a RuleSource in the record's own rail.", "source_edition": "live page as read 2026-09-20; the page states it was last updated about eleven months earlier", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps-return:src.natwest-faster-payment-reject-and-reason-codes", "id": "src.natwest-faster-payment-reject-and-reason-codes", "rail": "uk-fps-return", "class": "RuleSource", "name": "NatWest support centre, Understanding Faster Payment Rejection and Reason Codes", "summary": "A consumer-facing page from NatWest, a Faster Payments direct participant, with one table of reject and return reason codes and a plain explanation of each for a customer whose payment came back. It names ten return reasons individually and carries none above that. Source family A for these records; it corroborates only the reasons it names on their own.", "publisher": "NatWest", "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", "kind": "bank_support_page", "edition": "live page as read 2026-09-20; the page carries no date", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, fetched and read in full on 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for this rail. A RuleSource describes one edition of one document; its status stays draft and the monthly watch dates it through consulted_on. The same documents are held under uk-fps as well, because a corroboration names a RuleSource in the record's own rail.", "source_edition": "live page as read 2026-09-20; the page carries no date", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps-return:src.payuk-certainty-of-fate-rule-clarification-2026-01", "id": "src.payuk-certainty-of-fate-rule-clarification-2026-01", "rail": "uk-fps-return", "class": "RuleSource", "name": "Pay.UK's work on Certainty of Fate to support A2A retail transactions: proposed rule clarification, v1.0", "summary": "A Pay.UK consultation paper whose annex prints the current wording of the receiving institution's general obligations, including the duty to send Return Payments over Faster Payments specifying the return reason, what to do when transaction limits block a full return, and how a partial return must be made instead as a new payment with the originator's agreement.", "publisher": "Pay.UK Limited", "url": "https://www.wearepay.uk/wp-content/uploads/2026/01/Pay.UK-CoF-Proposed-Rule-Clarification-January-2026.pdf", "source_class": "public_primary", "kind": "consultation_paper", "edition": "v1.0, January 2026", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, fetched and read in full on 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for this rail. A RuleSource describes one edition of one document; its status stays draft and the monthly watch dates it through consulted_on. The same documents are held under uk-fps as well, because a corroboration names a RuleSource in the record's own rail.", "source_edition": "v1.0, January 2026", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "uk-fps-return:exc.return-payment", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:role.receiving-fps-institution", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:role.sending-fps-institution", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-return:rule.return-is-a-new-payment", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-return:rule.return-reason-required", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "uk-fps-return:src.payuk-fps-system-principles-v11", "id": "src.payuk-fps-system-principles-v11", "rail": "uk-fps-return", "class": "RuleSource", "name": "Faster Payments System Principles, FPS information guide, v11", "summary": "Pay.UK's public guide to the rail. For returns it gives the definition of a Return Payment as a new payment that references the original, the one to three working day window, and the separate Scheme Return Payment that only the central infrastructure can send. Section 1.4 says it is not a controlling specification.", "publisher": "Pay.UK Limited", "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", "kind": "information_guide", "edition": "v11, 2 January 2026", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, fetched and read in full on 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for this rail. A RuleSource describes one edition of one document; its status stays draft and the monthly watch dates it through consulted_on. The same documents are held under uk-fps as well, because a corroboration names a RuleSource in the record's own rail.", "source_edition": "v11, 2 January 2026", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "uk-fps-return:rail.uk-fps-return", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:exc.return-payment", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-return:role.receiving-fps-institution", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-return:rule.return-is-a-new-payment", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "uk-fps-return:txn.faster-payment", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "uk-fps-return:src.payuk-pfmi-self-assessment-2025", "id": "src.payuk-pfmi-self-assessment-2025", "rail": "uk-fps-return", "class": "RuleSource", "name": "2025 PFMI self-assessment of Pay.UK", "summary": "Pay.UK's assessment against the CPMI-IOSCO Principles for Financial Market Infrastructures. Key consideration 23.1 is the statement that the FPS rules and procedures are available for review by participants' legal departments and that the website carries only the list of system documentation, which is why every record here is marked as resting on sources other than the operator's own text.", "publisher": "Pay.UK Limited", "url": "https://www.wearepay.uk/wp-content/uploads/2025/11/2025-PFMI-self-assessment-of-Pay.UK_.pdf", "source_class": "public_primary", "kind": "regulatory_self_assessment", "edition": "position as at end of August 2025, published November 2025", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document itself, fetched and read in full on 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created 2026-09-20 for this rail. A RuleSource describes one edition of one document; its status stays draft and the monthly watch dates it through consulted_on. The same documents are held under uk-fps as well, because a corroboration names a RuleSource in the record's own rail.", "source_edition": "position as at end of August 2025, published November 2025", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "uk-fps-return:role.faster-payments-operator", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "uk-fps-return:txn.faster-payment", "id": "txn.faster-payment", "rail": "uk-fps-return", "class": "TransactionType", "name": "Faster Payment", "summary": "A sterling credit push over the Faster Payment System. A Return Payment is itself another credit push, referencing the original payment and going the other way, so nothing here is a debit. The code list makes no distinction between the payment types in any public source read.", "sec_code": null, "directions": [ "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "uk-fps-return:src.payuk-fps-system-principles-v11", "section": "sections 5 and 5.4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps:txn.return-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Faster Payments System Principles v11, sections 5 and 5.4, read 2026-09-20. sec_code is null: Faster Payments has no entry class code, and directions can only say credit because a return here is a fresh push and not a debit.", "confidence": "medium" }, "currency": { "effective_since": "Unknown: the public documents read do not date the payment types", "effective_to": null, "effective_note": "Drafted 2026-09-20. Pay.UK does not publish the FPS Procedures, Appendix B, FPS Codes, where the code list lives, so when this provision or this code first applied is [Unverified]; the dates given are the editions of the public documents read.", "source_edition": "Faster Payments System Principles v11 (2 January 2026), read 2026-09-20.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "uk-fps-return:src.payuk-fps-system-principles-v11", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms that every Faster Payments payment type, including a Return Payment, is a sterling credit push." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "uk-fps-return:00000001", "id": "00000001", "rail": "uk-fps-return", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "uk-fps-return:txn.faster-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "uk-fps-return:exc.return-payment", "evidence": [ { "source": "uk-fps-return:src.lhv-connect-payment-return-codes" }, { "source": "uk-fps-return:src.natwest-faster-payment-reject-and-reason-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "uk-fps-return:role.receiving-fps-institution", "evidence": [ { "source": "uk-fps-return:src.natwest-faster-payment-reject-and-reason-codes" } ], "note": "[Inference] NatWest's page describes each of these as a payment returned by the receiving bank. No public source read states the sender for this reason on its own.", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps:rule.return-payment-within-1-to-3-working-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-return:rule.return-is-a-new-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-return:rule.return-reason-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps:rule.rejection-and-return-code-lists-are-not-published", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps-return:00000002", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps-return:00000006", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "uk-fps-return:src.lhv-connect-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": "uk-fps-return:src.natwest-faster-payment-reject-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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps-return:00000002", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000005", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000006", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps-return:00000002", "id": "00000002", "rail": "uk-fps-return", "class": "ReasonCode", "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, "guidance": "Only with different account details. A retry to the same closed account will come back the same way." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "uk-fps-return:txn.faster-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "uk-fps-return:exc.return-payment", "evidence": [ { "source": "uk-fps-return:src.lhv-connect-payment-return-codes" }, { "source": "uk-fps-return:src.natwest-faster-payment-reject-and-reason-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "uk-fps-return:role.receiving-fps-institution", "evidence": [ { "source": "uk-fps-return:src.natwest-faster-payment-reject-and-reason-codes" } ], "note": "[Inference] NatWest's page describes each of these as a payment returned by the receiving bank. No public source read states the sender for this reason on its own.", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps:rule.return-payment-within-1-to-3-working-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-return:rule.return-is-a-new-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-return:rule.return-reason-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps:rule.rejection-and-return-code-lists-are-not-published", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps-return:00000001", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps-return:00000010", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "uk-fps-return:src.lhv-connect-payment-return-codes", "checked_on": "2026-09-20", "checked_by": "validator-2026-09-20", "notes": "Confirms return code 00000002 as creditor account closed." }, { "source": "uk-fps-return:src.natwest-faster-payment-reject-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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps-return:00000001", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000010", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps-return:00000005", "id": "00000005", "rail": "uk-fps-return", "class": "ReasonCode", "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, "guidance": "Send again with the reference filled in, once the returned funds are back." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "uk-fps-return:txn.faster-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "uk-fps-return:exc.return-payment", "evidence": [ { "source": "uk-fps-return:src.lhv-connect-payment-return-codes" }, { "source": "uk-fps-return:src.natwest-faster-payment-reject-and-reason-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "uk-fps-return:role.receiving-fps-institution", "evidence": [ { "source": "uk-fps-return:src.natwest-faster-payment-reject-and-reason-codes" } ], "note": "[Inference] NatWest's page describes each of these as a payment returned by the receiving bank. No public source read states the sender for this reason on its own.", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps:rule.return-payment-within-1-to-3-working-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-return:rule.return-is-a-new-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-return:rule.return-reason-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps:rule.rejection-and-return-code-lists-are-not-published", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps-return:00000001", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps-return:00000006", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "uk-fps-return:src.lhv-connect-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": "uk-fps-return:src.natwest-faster-payment-reject-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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps-return:00000006", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps-return:00000006", "id": "00000006", "rail": "uk-fps-return", "class": "ReasonCode", "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, "guidance": "Send again once the name is confirmed with the payee." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "uk-fps-return:txn.faster-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "uk-fps-return:exc.return-payment", "evidence": [ { "source": "uk-fps-return:src.lhv-connect-payment-return-codes" }, { "source": "uk-fps-return:src.natwest-faster-payment-reject-and-reason-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "uk-fps-return:role.receiving-fps-institution", "evidence": [ { "source": "uk-fps-return:src.natwest-faster-payment-reject-and-reason-codes" } ], "note": "[Inference] NatWest's page describes each of these as a payment returned by the receiving bank. No public source read states the sender for this reason on its own.", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps:rule.return-payment-within-1-to-3-working-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-return:rule.return-is-a-new-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-return:rule.return-reason-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps:rule.rejection-and-return-code-lists-are-not-published", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps-return:00000001", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps-return:00000005", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "uk-fps-return:src.lhv-connect-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": "uk-fps-return:src.natwest-faster-payment-reject-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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps-return:00000001", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000005", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps-return:00000007", "id": "00000007", "rail": "uk-fps-return", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "uk-fps-return:txn.faster-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "uk-fps-return:exc.return-payment", "evidence": [ { "source": "uk-fps-return:src.lhv-connect-payment-return-codes" }, { "source": "uk-fps-return:src.natwest-faster-payment-reject-and-reason-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "uk-fps-return:role.receiving-fps-institution", "evidence": [ { "source": "uk-fps-return:src.natwest-faster-payment-reject-and-reason-codes" } ], "note": "[Inference] The receiving institution sends the Return Payment, although the request behind it comes from the original sending side. No public source read states the sender for this reason on its own.", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps:rule.return-payment-within-1-to-3-working-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-return:rule.return-is-a-new-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-return:rule.return-reason-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps:rule.rejection-and-return-code-lists-are-not-published", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps-return:00000009", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "uk-fps-return:src.lhv-connect-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": "uk-fps-return:src.natwest-faster-payment-reject-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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps-return:00000009", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps-return:00000008", "id": "00000008", "rail": "uk-fps-return", "class": "ReasonCode", "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, "guidance": "Do not send the same payment again. Faster Payments carries sterling only, so it will come back the same way." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "uk-fps-return:txn.faster-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "uk-fps-return:exc.return-payment", "evidence": [ { "source": "uk-fps-return:src.lhv-connect-payment-return-codes" }, { "source": "uk-fps-return:src.natwest-faster-payment-reject-and-reason-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "uk-fps-return:role.receiving-fps-institution", "evidence": [ { "source": "uk-fps-return:src.natwest-faster-payment-reject-and-reason-codes" } ], "note": "[Inference] NatWest's page describes each of these as a payment returned by the receiving bank. No public source read states the sender for this reason on its own.", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps:rule.return-payment-within-1-to-3-working-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-return:rule.return-is-a-new-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-return:rule.return-reason-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps:rule.rejection-and-return-code-lists-are-not-published", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps-return:00000010", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "uk-fps-return:src.lhv-connect-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": "uk-fps-return:src.natwest-faster-payment-reject-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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps-return:00000010", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps-return:00000009", "id": "00000009", "rail": "uk-fps-return", "class": "ReasonCode", "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, "guidance": "Do not simply send it again. The payee refused the money, so find out why before sending anything further." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "uk-fps-return:txn.faster-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "uk-fps-return:exc.return-payment", "evidence": [ { "source": "uk-fps-return:src.lhv-connect-payment-return-codes" }, { "source": "uk-fps-return:src.natwest-faster-payment-reject-and-reason-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "uk-fps-return:role.receiving-fps-institution", "evidence": [ { "source": "uk-fps-return:src.natwest-faster-payment-reject-and-reason-codes" } ], "note": "[Inference] NatWest's page describes each of these as a payment returned by the receiving bank. No public source read states the sender for this reason on its own.", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps:rule.return-payment-within-1-to-3-working-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-return:rule.return-is-a-new-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-return:rule.return-reason-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps:rule.rejection-and-return-code-lists-are-not-published", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps-return:00000007", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "uk-fps-return:src.lhv-connect-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": "uk-fps-return:src.natwest-faster-payment-reject-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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps-return:00000007", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "uk-fps-return:00000010", "id": "00000010", "rail": "uk-fps-return", "class": "ReasonCode", "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, "guidance": "Not to the same account. The restriction is in the account's terms and will not change on a retry." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "uk-fps-return:txn.faster-payment" ], "excludes": [], "text": "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.", "relations": [ { "type": "raised_in", "to": "uk-fps-return:exc.return-payment", "evidence": [ { "source": "uk-fps-return:src.lhv-connect-payment-return-codes" }, { "source": "uk-fps-return:src.natwest-faster-payment-reject-and-reason-codes" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "uk-fps-return:role.receiving-fps-institution", "evidence": [ { "source": "uk-fps-return:src.natwest-faster-payment-reject-and-reason-codes" } ], "note": "[Inference] NatWest's page describes each of these as a payment returned by the receiving bank. No public source read states the sender for this reason on its own.", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps:rule.return-payment-within-1-to-3-working-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-return:rule.return-is-a-new-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps-return:rule.return-reason-required", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "uk-fps:rule.rejection-and-return-code-lists-are-not-published", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps-return:00000002", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "uk-fps-return:00000008", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "uk-fps-return:src.lhv-connect-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": "uk-fps-return:src.natwest-faster-payment-reject-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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "uk-fps-return:00000002", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps-return:00000008", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rail.us-ach", "id": "rail.us-ach", "class": "Rail", "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", "rule": "us-ach:rule.unauthorized-return-rate-threshold" }, "administrative": { "level": "3%", "kind": "inquiry threshold", "rule": "us-ach:rule.administrative-return-rate-threshold" }, "overall": { "level": "15%", "kind": "inquiry threshold", "rule": "us-ach:rule.overall-return-rate-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": [], "relations": [], "used_by": [] }, { "uid": "us-ach:cal.federal-reserve-banks", "id": "cal.federal-reserve-banks", "rail": "us-ach", "class": "Calendar", "name": "Federal Reserve Banks banking days", "summary": "The days on which the Reserve Banks, and so FedACH, count a banking day: Monday to Friday, less eleven federal holidays. A holiday that lands on a Sunday closes the Reserve Banks on the Monday after; one that lands on a Saturday closes nothing, and the Friday before stays a banking day. The list covers 2026 to 2030 as the operator published them. It is the operator's calendar, not any one bank's: a bank shut on a day the Reserve Banks are open is handled by its own Rule, and a funds transfer business day for an Article 4A credit is a separate term.", "timezone": "America/New_York", "business_days": [ "Mon", "Tue", "Wed", "Thu", "Fri" ], "holidays": [ { "date": "2026-01-01", "name": "New Year's Day" }, { "date": "2026-01-19", "name": "Martin Luther King Jr. Day" }, { "date": "2026-02-16", "name": "Washington's Birthday (Presidents Day)" }, { "date": "2026-05-25", "name": "Memorial Day" }, { "date": "2026-06-19", "name": "Juneteenth National Independence Day" }, { "date": "2026-07-04", "name": "Independence Day (falls on a Saturday; the Friday before stays a banking day)" }, { "date": "2026-09-07", "name": "Labor Day" }, { "date": "2026-10-12", "name": "Columbus Day" }, { "date": "2026-11-11", "name": "Veterans Day" }, { "date": "2026-11-26", "name": "Thanksgiving Day" }, { "date": "2026-12-25", "name": "Christmas Day" }, { "date": "2027-01-01", "name": "New Year's Day" }, { "date": "2027-01-18", "name": "Martin Luther King Jr. Day" }, { "date": "2027-02-15", "name": "Washington's Birthday (Presidents Day)" }, { "date": "2027-05-31", "name": "Memorial Day" }, { "date": "2027-06-19", "name": "Juneteenth National Independence Day (falls on a Saturday; the Friday before stays a banking day)" }, { "date": "2027-07-04", "name": "Independence Day (falls on a Sunday)" }, { "date": "2027-07-05", "name": "Independence Day (observed on the following Monday)" }, { "date": "2027-09-06", "name": "Labor Day" }, { "date": "2027-10-11", "name": "Columbus Day" }, { "date": "2027-11-11", "name": "Veterans Day" }, { "date": "2027-11-25", "name": "Thanksgiving Day" }, { "date": "2027-12-25", "name": "Christmas Day (falls on a Saturday; the Friday before stays a banking day)" }, { "date": "2028-01-01", "name": "New Year's Day (falls on a Saturday; the Friday before stays a banking day)" }, { "date": "2028-01-17", "name": "Martin Luther King Jr. Day" }, { "date": "2028-02-21", "name": "Washington's Birthday (Presidents Day)" }, { "date": "2028-05-29", "name": "Memorial Day" }, { "date": "2028-06-19", "name": "Juneteenth National Independence Day" }, { "date": "2028-07-04", "name": "Independence Day" }, { "date": "2028-09-04", "name": "Labor Day" }, { "date": "2028-10-09", "name": "Columbus Day" }, { "date": "2028-11-11", "name": "Veterans Day (falls on a Saturday; the Friday before stays a banking day)" }, { "date": "2028-11-23", "name": "Thanksgiving Day" }, { "date": "2028-12-25", "name": "Christmas Day" }, { "date": "2029-01-01", "name": "New Year's Day" }, { "date": "2029-01-15", "name": "Martin Luther King Jr. Day" }, { "date": "2029-02-19", "name": "Washington's Birthday (Presidents Day)" }, { "date": "2029-05-28", "name": "Memorial Day" }, { "date": "2029-06-19", "name": "Juneteenth National Independence Day" }, { "date": "2029-07-04", "name": "Independence Day" }, { "date": "2029-09-03", "name": "Labor Day" }, { "date": "2029-10-08", "name": "Columbus Day" }, { "date": "2029-11-11", "name": "Veterans Day (falls on a Sunday)" }, { "date": "2029-11-12", "name": "Veterans Day (observed on the following Monday)" }, { "date": "2029-11-22", "name": "Thanksgiving Day" }, { "date": "2029-12-25", "name": "Christmas Day" }, { "date": "2030-01-01", "name": "New Year's Day" }, { "date": "2030-01-21", "name": "Martin Luther King Jr. Day" }, { "date": "2030-02-18", "name": "Washington's Birthday (Presidents Day)" }, { "date": "2030-05-27", "name": "Memorial Day" }, { "date": "2030-06-19", "name": "Juneteenth National Independence Day" }, { "date": "2030-07-04", "name": "Independence Day" }, { "date": "2030-09-02", "name": "Labor Day" }, { "date": "2030-10-14", "name": "Columbus Day" }, { "date": "2030-11-11", "name": "Veterans Day" }, { "date": "2030-11-28", "name": "Thanksgiving Day" }, { "date": "2030-12-25", "name": "Christmas Day" } ], "observed": "A holiday on a Sunday moves to the following Monday, which is then not a banking day. A holiday on a Saturday is not moved, and the Friday before remains a banking day. Operating Circular 4 names the Sunday move for New Year's Day, Independence Day, Veterans Day and Christmas Day only; the operator's schedule page states it for any holiday. In 2026 to 2030 the two readings agree, because only Independence Day 2027 and Veterans Day 2029 fall on a Sunday.", "year_range": "2026-2030", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frbservices-holiday-schedules", "section": "the Holiday Schedule table for 2026 to 2030 and its two footnotes on Saturday and Sunday holidays, read 2026-09-26", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraph 2.1(h), the banking day definition; Appendix B section 1.1, the Reserve Banks' ACH banking day in Eastern Time; Appendix B section 4.1, the standard holidays and the Sunday rule, read 2026-09-26", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.hours-what-a-banking-day-is", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.hours-a-day-off-the-holiday-list-is-still-a-banking-day", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.hours-a-bank-closed-on-the-settlement-date", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Federal Reserve Financial Services holiday schedule page and Operating Circular 4 (effective 2026-01-05), both read 2026-09-26. The dates are the page's; the weekday of each was computed and matches the page's Saturday and Sunday footnote markers. The time zone is the Eastern Time the circular states for the ACH banking day. [Inference] Counting a Nacha banking-day window on this list assumes the Nacha banking day for the operator matches the Reserve Banks' own; the Nacha definition was not read, and a bank's own closures are outside this record.", "confidence": "medium" }, "currency": { "effective_since": "2026-01-05", "effective_to": null, "effective_note": "The date is the effective date of the Operating Circular 4 edition read. The operator reissues its holiday page each year, so the dates after 2026 may change; the monthly watch should re-read it.", "source_edition": "Federal Reserve System Holiday Schedule page as read 2026-09-26, listing 2026 to 2030; Federal Reserve Banks Operating Circular 4, effective 2026-01-05", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:exc.contested-dishonored-return", "id": "exc.contested-dishonored-return", "rail": "us-ach", "class": "Exception", "name": "Contested dishonored return", "summary": "The RDFI answers a dishonored return, either disputing it (the original return was on time, was not a duplicate, had no errors, or the dishonor itself was late or misrouted) or correcting the fields the ODFI said were wrong. It carries a code from R71 to R77.", "money_moves": true, "outcome": "A contest sent on time and without errors ends the matter inside the network: the ODFI must take it, and any further disagreement is settled outside the ACH Network.", "relations": [ { "type": "initiated_by", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "follows", "to": "us-ach:exc.dishonored-return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.contest-window-2-banking-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.contested-dishonor-ends-the-network-dispute", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "section": "codes to be used by RDFIs for contested dishonored return entries", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "section": "contested dishonored returns, page 11", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.bank-of-north-dakota-ach-overview-2024", "section": "ACH contested/corrected dishonored return reason codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "enters", "to": "us-ach:state.dishonor-contested", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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. The Nacha Operating Rules were 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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-core-2026-09-19", "notes": "Confirms an RDFI must transmit a contested dishonored return to the ACH Operator within two banking days after the settlement date of the dishonored return, using a code from R71 through R77." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.contest-window-2-banking-days", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R71", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R72", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R73", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R74", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R75", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R76", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R77", "type": "raised_in", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:exc.dishonored-return", "id": "exc.dishonored-return", "rail": "us-ach", "class": "Exception", "name": "Dishonored return", "summary": "The ODFI sends a return back to the RDFI because the return was late, misrouted, a duplicate, carried data that does not match the original entry, or claimed an ODFI request or agreement the ODFI never gave. It is a return of a return, marked with a code from R61 to R70.", "money_moves": true, "outcome": "The return is undone and its funds go back toward the RDFI. The RDFI may contest the dishonor within 2 banking days; if it does not, the dishonor stands.", "relations": [ { "type": "initiated_by", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "follows", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.dishonor-window-5-banking-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "section": "codes to be used by ODFIs for dishonored return entries", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "section": "dishonored returns, page 11", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.bank-of-north-dakota-ach-overview-2024", "section": "ACH dishonored return reason codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.treasury-green-book-2025-03", "section": "Returns chapter section D", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.return-returns-can-be-sent-back-again", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "enters", "to": "us-ach:state.return-dishonored", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "CBS Bank quick reference (March 2025), Jefferson Bank Obligations of Originators (March 2022), Bank of North Dakota ACH overview (2024) and the Treasury Green Book (2025-03), all read 2026-09-19. The Nacha Operating Rules were 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": "us-ach:src.treasury-green-book-2025-03", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-core-2026-09-19", "notes": "Confirms a dishonored return happens when the return item disagrees with the original payment data, that the disbursing office dishonors the return back to the financial institution, and that the financial institution can then correct the data and originate a contested return." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:exc.contested-dishonored-return", "type": "follows", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.dishonor-window-5-banking-days", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-dishonored-return-addenda", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R61", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R62", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R67", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R68", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R69", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R70", "type": "raised_in", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:exc.notification-of-change", "id": "exc.notification-of-change", "rail": "us-ach", "class": "Exception", "name": "Notification of change", "summary": "The RDFI, or a Gateway, tells the ODFI and Originator that data on an entry is wrong or out of date and gives the correct value, without sending the money back. The entry itself was handled; the notice is about the next ones.", "money_moves": false, "outcome": "The Originator changes its records for later entries to that account, or the ODFI refuses the NOC because the NOC itself cannot be used.", "relations": [ { "type": "initiated_by", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "initiated_by", "to": "us-ach:role.gateway", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-window-2-banking-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-originator-applies-the-change", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-odfi-passes-it-on-within-2-banking-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-rdfi-warrants-the-corrected-data", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "section": "Notifications of Change", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "section": "Notification of Change (NOC), page 15", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.treasury-green-book-2025-03", "section": "Notification of Change chapter", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.messages-correcting-the-data-rather-than-the-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "CBS Bank quick reference (March 2025), Jefferson Bank Obligations of Originators (March 2022) and the Treasury Green Book (2025-03), read 2026-09-19. decided_by Originator reads that the Originator decides whether to apply or, through its ODFI, refuse. [Inference]", "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": "us-ach:src.treasury-green-book-2025-03", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-core-2026-09-19", "notes": "Confirms a Notification of Change is a method a financial institution uses to tell a federal agency to correct or change account information for future entries, without sending money back." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:exc.refused-notification-of-change", "type": "follows", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-transaction-codes", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.noc-window-2-banking-days", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.participants-a-wrong-account-type-code-is-corrected-not-refused", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C01", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C02", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C03", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C05", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C06", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C07", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C08", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C09", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C13", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C14", "type": "raised_in", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:exc.refused-notification-of-change", "id": "exc.refused-notification-of-change", "rail": "us-ach", "class": "Exception", "name": "Refused notification of change", "summary": "The ODFI sends an NOC back to the RDFI because the NOC cannot be used: it went to the wrong bank, it cannot be matched to the original entry, or its corrected data is badly formatted or does not agree with the original. It carries a code from C61 to C69.", "money_moves": false, "outcome": "The Originator's records stay unchanged; the RDFI learns why and may send a proper NOC. [Inference]", "relations": [ { "type": "initiated_by", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "follows", "to": "us-ach:exc.notification-of-change", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.refused-noc-window-none-found", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "section": "ODFI change reason codes for refused NOCs", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "section": "refused Notification of Change codes, page 16", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.bank-of-north-dakota-ach-overview-2024", "section": "refusing an NOC", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.treasury-green-book-2025-03", "section": "Notification of Change chapter, section C", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "CBS Bank quick reference (March 2025), Jefferson Bank Obligations of Originators (March 2022), Bank of North Dakota ACH overview (2024) and Treasury Green Book (2025-03), read 2026-09-19.", "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": "us-ach:src.treasury-green-book-2025-03", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-core-2026-09-19", "notes": "Confirms a refused Notification of Change is an automated method the receiving agency uses to tell the originating financial institution that the change information it sent cannot be processed." }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-core-2026-09-19", "notes": "Confirms the ODFI change reason codes used for a refused Notification of Change run from C61 to C69." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.refused-noc-window-none-found", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C61", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C62", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C63", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C64", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C65", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C66", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C67", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C68", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C69", "type": "raised_in", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:exc.reg-e-error-claim", "id": "exc.reg-e-error-claim", "rail": "us-ach", "class": "Exception", "name": "Regulation E error claim", "summary": "A consumer tells their own bank that an electronic transfer, such as an ACH debit, was unauthorized or wrong. The bank investigates and decides whether an error occurred, on the Regulation E clock, whatever the ACH return windows say.", "money_moves": true, "outcome": "An error found: the bank corrects it and recredits the consumer, and may then recover through an ACH return or a warranty claim. No error: any provisional credit is reversed after notice.", "relations": [ { "type": "initiated_by", "to": "us-ach:role.receiver", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.reg-e-12-cfr-1005", "section": "1005.11", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "enters", "to": "us-ach:state.recredited-under-regulation-e", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Written for the 2026-09 Orca Core migration from the us-ach consumer-law, refund and decision-points facts, which cite 12 CFR 1005.11 as read 2026-09-17.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "12 CFR 1005 as on eCFR 2026-09-17", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.reg-e-12-cfr-1005", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-core-2026-09-19", "notes": "Confirms section 1005.11 lets a consumer notify their financial institution of an unauthorized or incorrect electronic fund transfer, that the institution must investigate and determine whether an error occurred, must correct a confirmed error, and must reverse any provisional credit after notice when it finds no error." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:mandate.consumer-debit-authorization", "type": "disputed_via", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:mandate.tel-debit-authorization", "type": "disputed_via", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:mandate.web-debit-authorization", "type": "disputed_via", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.consumer-law-the-error-clock", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.decision-points-whether-a-consumers-claim-is-an-error", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.refund-longer-clocks-for-new-accounts-and-some", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.refund-provisional-credit-while-the-bank-investigates", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.refund-the-consumers-statutory-route", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:exc.request-for-return", "id": "exc.request-for-return", "rail": "us-ach", "class": "Exception", "name": "Request for return", "summary": "The ODFI asks the RDFI to send an entry back. The RDFI decides whether to; if it does, the entry comes back as a return with R06.", "money_moves": false, "outcome": "Honored: an R06 return. Declined: the funds stay with the Receiver and recovery is outside the network.", "relations": [ { "type": "initiated_by", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Carried from us-ach:R06, whose summary, actions and caveat describe the request and the RDFI's choice.", "confidence": "medium" }, "currency": { "effective_since": "2024-10-01", "effective_to": null, "effective_note": "Expanded use of the request for return took effect 2024-10-01, per us-ach:R06.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-core-2026-09-19", "notes": "Confirms R06 covers an entry the ODFI has asked the RDFI to return, that the RDFI's return under this code is optional, and that the ODFI must indemnify the RDFI when the RDFI agrees to it." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.decision-points-whether-to-honour-a-request-to-return", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.recall-asking-rather-than-reversing", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.request-for-return-indemnity", "type": "part_of", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:exc.return", "id": "exc.return", "rail": "us-ach", "class": "Exception", "name": "Return", "summary": "An entry sent back toward the ODFI with a return reason code, usually by the RDFI and for some codes by the ACH Operator, a federal government agency or a Gateway. It settles in the opposite direction to the original entry.", "money_moves": true, "outcome": "The ODFI, and through it the Originator, receives the entry back with its reason code and acts on it.", "relations": [ { "type": "initiated_by", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "initiated_by", "to": "us-ach:role.ach-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "initiated_by", "to": "us-ach:role.federal-government-agency", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "initiated_by", "to": "us-ach:role.gateway", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "decided_by", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.written-statement-of-unauthorized-debit", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "enters", "to": "us-ach:state.returned", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Written for the 2026-09 Orca Core migration from general knowledge of the US ACH network and the us-ach reason code records that name it; no source consulted for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-core-2026-09-19", "notes": "Confirms an RDFI sends a return with a reason code toward the ODFI, that an ACH Operator itself may return an entry that fails its formatting edits, that a Gateway returns IAT entries using its own code series, and that a federal agency returns an ENR entry it cannot process." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:exc.dishonored-return", "type": "follows", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:mandate.consumer-debit-authorization", "type": "disputed_via", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:mandate.corporate-debit-agreement", "type": "disputed_via", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:mandate.tel-debit-authorization", "type": "disputed_via", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:mandate.web-debit-authorization", "type": "disputed_via", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-ctx-return", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-return-entry-construction", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-transaction-codes", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.hours-a-bank-closed-on-the-settlement-date", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-gateway-only-return-codes", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-no-dishonored-returns", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-ofac-hold-before-posting", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-return-addenda", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-return-amount-may-differ", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-return-timeframes", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.participants-only-the-receiving-bank-may-derive-a-return-or-noc", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.return-the-operator-stops-a-second-return-it-can-see", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.return-what-a-blocked-debit-comes-back-as", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.return-what-a-processor-calls-a-late-return", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.return-window-2-banking-days", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.return-window-60-calendar-days", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.return-window-enr-agency", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.return-window-late-by-agreement", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.return-window-next-file-delivery", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.return-window-odfi-request", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.return-window-operator-reject", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.return-window-refused-credit", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.return-window-sanctions-determination", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.same-day-return-not-before-forward", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.same-day-returns-regardless-of-forward", "type": "part_of", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R01", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R02", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R03", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R04", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R05", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R06", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R07", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R08", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R09", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R10", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R11", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R12", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R13", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R14", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R15", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R16", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R17", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R18", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R19", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R20", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R21", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R22", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R23", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R24", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R25", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R26", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R27", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R28", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R29", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R30", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R31", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R32", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R33", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R34", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R35", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R36", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R37", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R38", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R39", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R40", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R41", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R42", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R43", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R44", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R45", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R46", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R47", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R50", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R51", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R52", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R53", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R80", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R81", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R82", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R83", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R84", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R85", "type": "raised_in", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R90", "type": "raised_in", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:mandate.consumer-debit-authorization", "id": "mandate.consumer-debit-authorization", "rail": "us-ach", "class": "Mandate", "name": "Consumer authorization of a debit", "summary": "The Receiver, a consumer, authorizes the Originator to debit their account, once or on a schedule. The consumer unauthorized return reasons are how the Receiver disputes a debit this authorization does not cover.", "form": "signed paper, recorded oral (TEL) or electronic (WEB) [Inference]", "scope": [ "single", "recurring" ], "relations": [ { "type": "given_by", "to": "us-ach:role.receiver", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "given_to", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "authorises", "to": "us-ach:txn.ppd", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "authorises", "to": "us-ach:txn.web", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "authorises", "to": "us-ach:txn.tel", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "disputed_via", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.consumer-law-authorisation-for-a-recurring-debit-must-be", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "revoked_via", "to": "us-ach:rule.consumer-law-the-stop-payment-right", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.consumer-law-warning-when-the-amount-changes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "disputed_via", "to": "us-ach:exc.reg-e-error-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.authorization-general-requirements", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.authorization-ppd", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:mandate.web-debit-authorization", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:mandate.tel-debit-authorization", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Written for the 2026-09 Orca Core migration from the authorization codes us-ach:R05, R07, R10 and R11, whose actions name signed forms, recorded calls and web authorizations; no source consulted. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.tompkins-originating-ach-quick-reference", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that a consumer debit rests on the Receiver's authorization, taken as a signed PPD form, a recorded or confirmed TEL call, or a written WEB authorization, once or on a recurring schedule." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:mandate.authorised-payment-mandate", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:mandate.tel-debit-authorization", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:mandate.web-debit-authorization", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R05", "type": "concerns", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R07", "type": "concerns", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R10", "type": "concerns", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R11", "type": "concerns", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:mandate.corporate-debit-agreement", "id": "mandate.corporate-debit-agreement", "rail": "us-ach", "class": "Mandate", "name": "Business authorization of entries under an agreement (CCD, CTX)", "summary": "A business Receiver authorizes the Originator, by agreement, to send entries to its account and agrees to be bound by the Nacha rules. The rules set no form for the agreement. A business that did not authorize a debit returns it as R29 within the ordinary window.", "form": "agreement between the Originator and the business Receiver; form not set by the rules", "scope": [ "single", "recurring" ], "relations": [ { "type": "given_by", "to": "us-ach:role.receiver", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "given_to", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "authorises", "to": "us-ach:txn.ccd", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "authorises", "to": "us-ach:txn.ctx", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.authorization-ccd-ctx", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "disputed_via", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R29", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Rests on rule.authorization-ccd-ctx, whose sources are the Tompkins Bank & Trust and Nicolet National Bank Originator guides, read 2026-09-19, and on the existing us-ach:R29 record for the return. scope single and recurring is Orca's reading. [Inference]", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19; no rule change identified.", "source_edition": "Nacha public documents read 2026-09-19; bank guides undated, read 2026-09-19; Nacha Operating Rules not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.tompkins-originating-ach-quick-reference", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that a CCD or CTX entry rests on an agreement between the corporate Originator and Receiver binding each to the Nacha rules, with no form prescribed for it." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:mandate.tel-debit-authorization", "id": "mandate.tel-debit-authorization", "rail": "us-ach", "class": "Mandate", "name": "Consumer authorization of a debit by telephone (TEL)", "summary": "The Receiver, a consumer who has an existing relationship with the Originator or who placed the call, authorizes a debit orally by phone. A single debit is recorded or confirmed in writing before settlement; a recurring authorization is both recorded and confirmed in writing.", "form": "oral, by telephone, recorded or confirmed in writing", "scope": [ "single", "recurring" ], "relations": [ { "type": "given_by", "to": "us-ach:role.receiver", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "given_to", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "authorises", "to": "us-ach:txn.tel", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.authorization-general-requirements", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.authorization-tel", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "revoked_via", "to": "us-ach:rule.consumer-law-the-stop-payment-right", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "disputed_via", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "disputed_via", "to": "us-ach:exc.reg-e-error-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:mandate.consumer-debit-authorization", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Rests on the Rules it is governed_by: the Tompkins Bank & Trust and Nicolet National Bank Originator guides, read 2026-09-19. The revocation and dispute links are Orca's reading that a TEL debit is a consumer electronic fund transfer like any other. [Inference] The Nacha Operating Rules were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19; no rule change identified.", "source_edition": "Nacha public documents read 2026-09-19; bank guides undated, read 2026-09-19; Nacha Operating Rules not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.tompkins-originating-ach-quick-reference", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the existing-relationship-or-consumer-call condition for oral TEL authorization and the recording or written confirmation timing before settlement for a single debit and before the first settlement for a recurring one." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:mandate.consumer-debit-authorization", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:mandate.web-debit-authorization", "id": "mandate.web-debit-authorization", "rail": "us-ach", "class": "Mandate", "name": "Consumer authorization for an internet or mobile debit (WEB)", "summary": "The Receiver, a consumer, authorizes the Originator over the internet or a wireless network to debit their account, once or on a schedule. The authorization is written and similarly authenticated; the Originator must authenticate the consumer, validate the account at its first use, and be able to show the process that tied the authorization to the consumer.", "form": "written, given over the internet or a wireless network and similarly authenticated", "scope": [ "single", "recurring" ], "relations": [ { "type": "given_by", "to": "us-ach:role.receiver", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "given_to", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "authorises", "to": "us-ach:txn.web", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.authorization-general-requirements", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.authorization-web", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.web-debit-account-validation", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.consumer-law-authorisation-for-a-recurring-debit-must-be", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.consumer-law-warning-when-the-amount-changes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "revoked_via", "to": "us-ach:rule.consumer-law-the-stop-payment-right", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "disputed_via", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "disputed_via", "to": "us-ach:exc.reg-e-error-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:mandate.consumer-debit-authorization", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Rests on the Rules it is governed_by: Nacha's WEB proof of authorization paper and WEB validation page, and the Tompkins Bank & Trust Originator guide, read 2026-09-19. The Regulation E links repeat the existing consumer-law Rules. The Nacha Operating Rules were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19; no rule change identified.", "source_edition": "Nacha public documents read 2026-09-19; bank guides undated, read 2026-09-19; Nacha Operating Rules not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-web-proof-of-authorization-2022", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that a WEB authorization is written and similarly authenticated, that the Originator must authenticate the consumer, and that the Originator must be able to show the process, such as login timestamp and IP address, that tied the authorization to the consumer." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:mandate.consumer-debit-authorization", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:role.ach-operator", "id": "role.ach-operator", "rail": "us-ach", "class": "Role", "name": "ACH Operator", "summary": "A central clearing facility that moves entries between ODFIs and RDFIs and rejects entries that fail its edits before they reach the RDFI.", "kind": "operator", "relations": [], "basis": { "sources": "Written for the 2026-09 Orca Core migration from general knowledge of the US ACH network and the us-ach reason code records that name it; no source consulted for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-how-ach-payments-work", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-core-2026-09-19", "notes": "Confirms the ACH Operator sits between the ODFI and the RDFI and sorts and routes entries to their destination bank." }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-core-2026-09-19", "notes": "Confirms the ACH Operator checks entries against ACH record formatting specifications and rejects entries that fail that edit before they reach the destination financial institution, and may itself return or reject a batch or file." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:exc.return", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.decision-points-what-a-bank-can-cap-in-operator-monitoring", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-batch-header-holds-what-entries-share", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-mandatory-required-optional-fields", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.hours-a-day-off-the-holiday-list-is-still-a-banking-day", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.hours-a-deadline-stated-in-hours-runs-on-the-clock", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-addenda-structure", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-gateway-inbound-debit-limits", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-ofac-screening-duties", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-separate-file-option", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.messages-a-suspected-duplicate-file-waits-for-the-sender", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.messages-the-operator-acknowledges-a-file-it-has-taken-in", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.noc-same-day-and-fee", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.operator-derives-dishonors-and-contests", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.participants-only-the-receiving-bank-may-derive-a-return-or-noc", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.return-the-operator-stops-a-second-return-it-can-see", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.return-window-next-file-delivery", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.return-window-operator-reject", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.same-day-entry-fee", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.same-day-fedach-operator-charges", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.same-day-ineligible-entry-settles-next-day", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.same-day-no-deadline-extensions", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.same-day-return-not-before-forward", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.same-day-returns-regardless-of-forward", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.same-day-risk-pended-batches", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.same-day-statement-identification", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R13", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R18", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R19", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R25", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R26", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R27", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R28", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R30", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R32", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R34", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R35", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R36", "type": "returned_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:role.federal-government-agency", "id": "role.federal-government-agency", "rail": "us-ach", "class": "Role", "name": "Federal government agency", "summary": "A federal agency that receives automated enrollment entries (ENR) for federal benefit payments and returns those it cannot act on.", "kind": "party", "relations": [], "basis": { "sources": "Written for the 2026-09 Orca Core migration from general knowledge of the US ACH network and the us-ach reason code records that name it; no source consulted for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.treasury-green-book-2025-03", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-core-2026-09-19", "notes": "Confirms a federal benefit agency receives ENR automated enrollment entries from a financial institution and may return an ENR entry it cannot process, using codes such as non-participant in the ENR program, an invalid transaction code, or a duplicate enrollment." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:exc.return", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-enr-entry-codes", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.noc-federal-agencies-accept-six-codes", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.return-window-enr-agency", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.same-day-government-entries", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R40", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R41", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R42", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R43", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R44", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R45", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R46", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R47", "type": "returned_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:role.foreign-correspondent-bank", "id": "role.foreign-correspondent-bank", "rail": "us-ach", "class": "Role", "name": "Foreign Correspondent Bank", "summary": "A participating DFI in a foreign country that holds deposits for other financial institutions and provides them payment services. In an inbound IAT it is the foreign originating bank's correspondent, identified in the optional foreign correspondent addenda (type 18), up to five of them; whether the US Gateway or the foreign gateway fills them is agreed between the two.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-web", "section": "General: what a Foreign Correspondent Bank is", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-2021-03-09", "section": "questions 7, 66 and 83", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-iat-faqs", "section": "Format Questions: the Foreign Correspondent Bank Information addenda record", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules were not consulted. Since 2026-09-18 its definition (Section 8.45) refers to financial agency in a generic sense, per Nacha's Definition of IAT Entries page.", "confidence": "medium" }, "currency": { "effective_since": "2009-09-18", "effective_to": null, "effective_note": "Role defined with the IAT rule in force since 2009-09-18; the 2026-09-18 rule revised the wording of its definition (Section 8.45) without a change identified in substance [Unverified].", "source_edition": "Nacha IAT FAQs and Federal Reserve IAT FAQ, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-iat-faqs-2021-03-09", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-core-2026-09-19", "notes": "Confirms a Foreign Correspondent Bank is a participating DFI in a foreign country that holds deposits owned by other financial institutions and provides payment and other services to them, and that the Foreign Correspondent addenda of an inbound IAT is populated by whichever Gateway the two Gateways agree will do it." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:role.gateway", "id": "role.gateway", "rail": "us-ach", "class": "Role", "name": "Gateway", "summary": "The Gateway Operator: an ACH Operator or a participating DFI that is the point where an ACH entry enters or leaves the United States, and that carries warranties and duties of its own for IAT entries. The Federal Reserve acts as one for FedGlobal.", "kind": "institution", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-web", "section": "General: what a Gateway Operator is", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-iat-executive-summary-2008-07-31", "section": "Rules Framework item 2", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Written for the 2026-09 Orca Core migration from general knowledge; summary revised and sourced 2026-09-19 from the Nacha IAT FAQ web page and the 2008 IAT executive summary, both read that day.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; summary sourced 2026-09-19. No rule change identified.", "source_edition": "Nacha IAT FAQ web page (dated 2021-05-19) and IAT executive summary (2008-07-31), read 2026-09-19; Nacha Operating Rules not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-iat-faqs-web", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-core-2026-09-19", "notes": "Confirms a Gateway Operator can be either an ACH Operator or a participating depository financial institution that acts as the entry or exit point for ACH payments crossing the US border, and that the Federal Reserve acts as a Gateway Operator for its FedGlobal ACH service." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:exc.notification-of-change", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:exc.return", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-addenda-structure", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-contact-registry-from-2027", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-date-of-birth-field-from-2027", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-definition", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-fedglobal-service-scope", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-foreign-exchange-fields", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-gateway-agreement-with-odfi", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-gateway-inbound-debit-limits", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-gateway-only-return-codes", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-gateway-operator-defined", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-notifications-of-change", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-ofac-screening-duties", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-ofac-screening-indicators", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-party-information-every-entry", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-prenotes", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-replaced-cbr-and-pbr", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-return-addenda", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.noc-window-2-banking-days", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.participants-gateway-screening-does-not-move-the-duty", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.return-window-sanctions-determination", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C14", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R80", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R81", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R82", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R83", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R84", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R85", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R90", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:role.nested-third-party-sender", "id": "role.nested-third-party-sender", "rail": "us-ach", "class": "Role", "name": "Nested Third-Party Sender", "summary": "Nested Third-Party Sender: a Third-Party Sender that acts for an Originator under an agreement with another Third-Party Sender and has no agreement of its own with the ODFI. It carries the duties of a Third-Party Sender, including its own audit and risk assessment, and the ODFI flags in its Nacha registration which of its Third-Party Senders allow nested ones.", "kind": "service_provider", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-third-party-sender-roles", "section": "Technical: Nested Third-Party Sender", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-third-parties-in-the-ach-network", "section": "Key Definitions", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.umacha-third-party-services", "section": "definitions", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "2022-09-30", "effective_to": null, "effective_note": "Defined by the Nacha rule effective 2022-09-30.", "source_edition": "Nacha public rule page for the rule effective 2022-09-30, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-third-parties-in-the-ach-network", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms a Nested Third-Party Sender is a Third-Party Sender that originates through another Third-Party Sender rather than directly with an Originating Depository Financial Institution." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.tps-annual-rules-compliance-audit", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.tps-nested-chain-of-agreements", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.tps-risk-assessment", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:role.odfi", "id": "role.odfi", "rail": "us-ach", "class": "Role", "name": "ODFI", "summary": "Originating Depository Financial Institution: the bank that sends entries into the network for its Originator and receives their returns.", "kind": "institution", "relations": [], "basis": { "sources": "Written for the 2026-09 Orca Core migration from general knowledge of the US ACH network and the us-ach reason code records that name it; no source consulted for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-how-ach-payments-work", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-core-2026-09-19", "notes": "Confirms the ODFI is the Originator's bank, that it sends the Originator's payment files onward to an ACH Operator, and confirms through the Green Book glossary that the ODFI is the financial institution that delivers ACH entries to its ACH Operator." }, { "source": "us-ach:src.treasury-green-book-2025-03", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-core-2026-09-19", "notes": "Confirms in its glossary that the ODFI is the financial institution that delivers ACH entries directly or indirectly through a third party to its ACH Operator." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:exc.dishonored-return", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:exc.dishonored-return", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:exc.refused-notification-of-change", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:exc.refused-notification-of-change", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:exc.request-for-return", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.contested-dishonor-ends-the-network-dispute", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.decision-points-what-a-bank-can-cap-in-operator-monitoring", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.dishonor-window-5-banking-days", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-balanced-and-unbalanced-files", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-batch-control-totals", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-batch-header-holds-what-entries-share", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-dishonored-return-addenda", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-file-header-and-control", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-trace-number-assignment", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.hours-a-bank-closed-on-the-settlement-date", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.hours-same-day-transmission-deadlines", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-addenda-structure", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-contact-registry-from-2027", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-date-of-birth-field-from-2027", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-definition", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-fedglobal-service-scope", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-foreign-exchange-fields", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-gateway-agreement-with-odfi", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-gateway-inbound-debit-limits", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-no-dishonored-returns", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-notifications-of-change", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-ofac-screening-duties", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-party-information-every-entry", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-prenotes", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-return-amount-may-differ", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-return-timeframes", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-reversal-best-effort", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-us-jurisdiction-is-domestic", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.liability-outsourced-screening-stays-the-bank-s-problem", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.limits-the-ceiling-that-is-coming", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.limits-the-odfi-sets-an-exposure-limit-on-its-originator", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.limits-the-same-day-ach-ceiling-today", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.messages-the-operator-acknowledges-a-file-it-has-taken-in", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.messages-the-travel-rule-threshold-and-what-an-iat-carries", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.noc-odfi-passes-it-on-within-2-banking-days", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.odfi-oversight-of-third-party-senders", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.participants-what-an-odfi-checks-before-an-originator-starts", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.participants-who-screens-a-domestic-entry-for-sanctions", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.prenote-response-deadline-and-originator-action", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.refused-noc-window-none-found", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.request-for-return-indemnity", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.same-day-entry-fee", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.same-day-fedach-operator-charges", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.same-day-government-entries", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.same-day-ineligible-entry-settles-next-day", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.same-day-no-deadline-extensions", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.same-day-risk-pended-batches", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.tps-nested-chain-of-agreements", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.tps-origination-agreements", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.tps-registration", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C61", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C62", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C63", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C64", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C65", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C66", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C67", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C68", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C69", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R61", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R62", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R67", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R68", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R69", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R70", "type": "returned_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:role.originator", "id": "role.originator", "rail": "us-ach", "class": "Role", "name": "Originator", "summary": "The business or person that authorizes its ODFI to send entries to a Receiver's account.", "kind": "party", "relations": [], "basis": { "sources": "Written for the 2026-09 Orca Core migration from general knowledge of the US ACH network and the us-ach reason code records that name it; no source consulted for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-how-ach-payments-work", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-core-2026-09-19", "notes": "Confirms the Originator is the business or person, such as an employer running payroll or a company collecting a bill payment, whose bank is the ODFI and who authorizes the entries the ODFI sends." }, { "source": "us-ach:src.nicolet-ach-quick-reference-guide", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-core-2026-09-19", "notes": "Confirms the Originator is the entity authorized by the Receiver to credit or debit the Receiver's account, and that the Originator holds the contractual relationship for ACH services with its ODFI." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:exc.notification-of-change", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:mandate.consumer-debit-authorization", "type": "given_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:mandate.corporate-debit-agreement", "type": "given_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:mandate.tel-debit-authorization", "type": "given_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:mandate.web-debit-authorization", "type": "given_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.administrative-return-rate-threshold", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.authorization-ccd-ctx", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.authorization-general-requirements", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.authorization-ppd", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.authorization-tel", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.authorization-web", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.consumer-law-a-returned-payment-fee-is-its-own-debit", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.consumer-law-authorisation-for-a-recurring-debit-must-be", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-addenda-indicator-and-linking", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-balanced-and-unbalanced-files", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-batch-control-totals", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-batch-header-holds-what-entries-share", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-blocking-and-padding", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-cie-mte-name-and-identification", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-field-fill-conventions", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-file-header-and-control", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-mandatory-required-optional-fields", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-record-line-ending", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-transaction-codes", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-definition", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-gateway-agreement-with-odfi", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-ofac-screening-duties", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-party-information-every-entry", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-us-jurisdiction-is-domestic", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.micro-entries-amounts-and-timing", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.micro-entries-definition-and-labels", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.micro-entries-fraud-monitoring", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.micro-entries-receiver-confirmation", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.no-reinitiation-without-new-authorization", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.noc-originator-applies-the-change", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.overall-return-rate-threshold", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.practice-instant-verification-and-micro-deposits", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.prenote-optional-zero-dollar-entry", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.prenote-response-deadline-and-originator-action", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.prenote-wait-before-live-entries", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.r11-corrected-entry", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.reinitiation-after-funds-return", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.tps-origination-agreements", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.tps-which-role-an-intermediary-plays", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.unauthorized-return-rate-threshold", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.web-debit-account-validation", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.web-validation-after-noc", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.web-validation-commercially-reasonable", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.web-validation-existing-accounts", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.web-validation-methods", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.web-validation-prenote-and-micro-entry-results", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.web-validation-what-it-confirms", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:role.rdfi", "id": "role.rdfi", "rail": "us-ach", "class": "Role", "name": "RDFI", "summary": "Receiving Depository Financial Institution: the bank or credit union that holds the Receiver's account, posts the entry, and returns it when a return reason applies.", "kind": "institution", "relations": [], "basis": { "sources": "Written for the 2026-09 Orca Core migration from general knowledge of the US ACH network and the us-ach reason code records that name it; no source consulted for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-how-ach-payments-work", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-core-2026-09-19", "notes": "Confirms the RDFI is the Receiver's bank or credit union and that it withdraws or posts the funds for the Receiver." }, { "source": "us-ach:src.treasury-green-book-2025-03", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-core-2026-09-19", "notes": "Confirms in its glossary that for purposes of the Green Book the RDFI is the financial institution that receives the payment, and that an RDFI may return a debit or credit item to a Reserve Bank." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:exc.contested-dishonored-return", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:exc.contested-dishonored-return", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:exc.notification-of-change", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:exc.reg-e-error-claim", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:exc.request-for-return", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:exc.return", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:exc.return", "type": "decided_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.consumer-law-the-error-clock", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.contest-window-2-banking-days", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.decision-points-blocking-or-filtering-incoming-debits", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.decision-points-what-a-false-positive-is-on-a-sanctions-screen", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.decision-points-whether-a-consumers-claim-is-an-error", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.decision-points-whether-to-honour-a-request-to-return", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-ctx-return", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-enr-entry-codes", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-mandatory-required-optional-fields", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-return-entry-construction", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-transaction-codes", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.hours-a-bank-closed-on-the-settlement-date", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.hours-same-day-credit-funds-availability", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-contact-registry-from-2027", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-date-of-birth-field-from-2027", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-gateway-agreement-with-odfi", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-no-dishonored-returns", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-notifications-of-change", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-ofac-hold-before-posting", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-ofac-screening-duties", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-ofac-screening-indicators", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-one-code-consumer-and-business", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-rdfi-must-accept", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-replaced-cbr-and-pbr", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-return-addenda", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-return-timeframes", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-separate-file-option", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.liability-outsourced-screening-stays-the-bank-s-problem", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.limits-ach-debits-to-a-savings-account", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.noc-more-than-one-per-entry", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.noc-rdfi-warrants-the-corrected-data", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.noc-window-2-banking-days", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.participants-a-wrong-account-type-code-is-corrected-not-refused", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.participants-gateway-screening-does-not-move-the-duty", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.participants-only-the-receiving-bank-may-derive-a-return-or-noc", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.participants-posting-rests-on-the-account-number", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.participants-who-screens-a-domestic-entry-for-sanctions", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.prenote-optional-zero-dollar-entry", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.refund-longer-clocks-for-new-accounts-and-some", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.refund-provisional-credit-while-the-bank-investigates", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.refund-the-consumers-statutory-route", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.return-window-2-banking-days", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.return-window-60-calendar-days", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.return-window-late-by-agreement", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.return-window-odfi-request", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.return-window-refused-credit", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.return-window-sanctions-determination", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.same-day-entry-fee", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.same-day-return-not-before-forward", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.same-day-returns-regardless-of-forward", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.web-validation-after-noc", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.written-statement-of-unauthorized-debit", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C01", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C02", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C03", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C05", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C06", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C07", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C08", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C09", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C13", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R01", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R02", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R03", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R04", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R05", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R06", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R07", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R08", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R09", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R10", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R11", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R12", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R14", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R15", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R16", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R17", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R20", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R21", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R22", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R23", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R24", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R29", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R31", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R33", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R37", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R38", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R39", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R50", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R51", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R52", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R53", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R71", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R72", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R73", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R74", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R75", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R76", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R77", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R85", "type": "returned_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R90", "type": "returned_by", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:role.receiver", "id": "role.receiver", "rail": "us-ach", "class": "Role", "name": "Receiver", "summary": "The business or person whose account an entry credits or debits, and who authorizes an Originator to debit it.", "kind": "party", "relations": [], "basis": { "sources": "Written for the 2026-09 Orca Core migration from general knowledge of the US ACH network and the us-ach reason code records that name it; no source consulted for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-how-ach-payments-work", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-core-2026-09-19", "notes": "Confirms the Receiver is the person or business whose account is credited or debited, illustrated by an employee receiving a payroll deposit and a customer paying a bill by ACH debit." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:exc.reg-e-error-claim", "type": "initiated_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:mandate.consumer-debit-authorization", "type": "given_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:mandate.corporate-debit-agreement", "type": "given_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:mandate.tel-debit-authorization", "type": "given_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:mandate.web-debit-authorization", "type": "given_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.decision-points-blocking-or-filtering-incoming-debits", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.participants-who-an-account-holder-asks-about-a-payment", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:role.third-party-sender", "id": "role.third-party-sender", "rail": "us-ach", "class": "Role", "name": "Third-Party Sender", "summary": "Third-Party Sender (TPS): a Third-Party Service Provider that stands between an Originator and the ODFI and, instead of the Originator, holds the origination agreement with the ODFI. It transmits entries for its Originators, and may do so for a Nested Third-Party Sender. It takes on many of the ODFI's duties toward its Originators, is registered with Nacha by its ODFI, and must have its own annual Rules compliance audit and its own risk assessment. The same business can be a TPS for some entries and the Originator of others.", "kind": "service_provider", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-third-parties-in-the-ach-network", "section": "Key Definitions; Rules and Compliance", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-ops-bulletin-2-2014-third-party-senders", "section": "Discussion, pages 1 to 3; the definition then in Section 8.104", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-third-party-sender-roles", "section": "Details and Technical", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.umacha-third-party-services", "section": "definitions and audit and risk assessment requirements", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules were not consulted. The definition was revised on 2014-03-21, per the 2014 bulletin.", "confidence": "medium" }, "currency": { "effective_since": "2014-03-21", "effective_to": null, "effective_note": "The current definition dates from the rule change effective 2014-03-21, per Nacha's 2014 bulletin; nested senders were added to it from 2022-09-30.", "source_edition": "Nacha public pages and ACH Operations Bulletin #2-2014, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-third-parties-in-the-ach-network", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms a Third-Party Sender is a specific kind of Third-Party Service Provider that acts on behalf of an Originator to transmit entries through an ODFI without a direct agreement between the Originator and the ODFI, and that the Nacha Rules require annual Rules Compliance Audits and risk assessments of Third-Party Senders and define the relationships between ODFIs, Third-Party Senders, Nested Third-Party Senders and Originators." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.participants-what-an-odfi-checks-before-an-originator-starts", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.tps-annual-rules-compliance-audit", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.tps-company-name-and-identification", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.tps-duties-and-warranties", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.tps-nested-chain-of-agreements", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.tps-origination-agreements", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.tps-payment-facilitators", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.tps-registration", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.tps-risk-assessment", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.tps-which-role-an-intermediary-plays", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:role.third-party-service-provider", "id": "role.third-party-service-provider", "rail": "us-ach", "class": "Role", "name": "Third-Party Service Provider", "summary": "Third-Party Service Provider (TPSP): any party that performs ACH processing functions for an Originator, an ODFI or an RDFI, such as building files, whether or not it transmits entries itself. A Third-Party Sender is one particular kind of TPSP. A TPSP must have an annual Rules compliance audit of the functions it performs for a financial institution or a Third-Party Sender.", "kind": "service_provider", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-third-parties-in-the-ach-network", "section": "Key Definitions; Rules and Compliance", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-ops-bulletin-2-2014-third-party-senders", "section": "Discussion, pages 1 to 3", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Definition as Nacha's page gives it on 2026-09-19; no change date identified.", "source_edition": "Nacha public pages, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-third-parties-in-the-ach-network", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms a Third-Party Service Provider provides services related to ACH processing on behalf of another party and may or may not transmit entries directly, and that the Nacha Rules require it to complete an annual Rules Compliance Audit covering the functions it performs for a Participating DFI or a Third-Party Sender." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.liability-outsourced-screening-stays-the-bank-s-problem", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.tps-annual-rules-compliance-audit", "type": "binds", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.tps-which-role-an-intermediary-plays", "type": "binds", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.administrative-return-rate-threshold", "id": "rule.administrative-return-rate-threshold", "rail": "us-ach", "class": "Rule", "name": "Administrative return rate level: 3 percent", "statement": "An Originator's rate of debit returns for the administrative reasons linked to it above 3 percent triggers an inquiry.", "rests_on": "rule", "facet": "return", "parameters": { "limit": { "rate": 3, "unit": "percent", "measured_over": "debit entries over the preceding 60 days [Unverified]", "text": "3%" } }, "relations": [ { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the rates block of corpus/us-ach/meta.json and the counts_toward lists of the us-ach codes by the 2026-09 Orca Core migration. No source has been checked for it.", "confidence": "low" }, "currency": { "effective_since": "2015-09-18", "effective_to": null, "effective_note": "The 3 percent level took force 2015-09-18, per the effective notes of us-ach:R02 and R04.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R02", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R03", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R04", "type": "counts_toward", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.authorization-ccd-ctx", "id": "rule.authorization-ccd-ctx", "rail": "us-ach", "class": "Rule", "name": "Authorization for CCD and CTX entries: an agreement between businesses", "statement": "CCD and CTX entries rest on an agreement between the Originator and the business Receiver, under which the Receiver authorizes entries to its account and agrees to be bound by the Nacha rules. The rules do not define what form that agreement takes; banks recommend having the business complete an authorization form.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.ccd", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.ctx", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.tompkins-originating-ach-quick-reference", "section": "Originating CCD Entries", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nicolet-ach-quick-reference-guide", "section": "Corporate Authorizations", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.authorization-general-requirements", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Nacha's WEB proof of authorization paper (2022) and its 2025-11-03 article, and two bank guides for Originators, read 2026-09-19; the Nacha Operating Rules text was not consulted, and where the Nacha paper cites a rule subsection the record repeats the cite without having read it.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from the public sources its sourced_from links name; no rule change identified after the date given.", "source_edition": "Nacha public documents read 2026-09-19; bank guides undated, read 2026-09-19; Nacha Operating Rules not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.tompkins-originating-ach-quick-reference", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that CCD authorization rests on an agreement between the corporate Originator and Receiver binding each to the Nacha rules, with no prescribed form." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:mandate.corporate-debit-agreement", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.authorization-general-requirements", "id": "rule.authorization-general-requirements", "rail": "us-ach", "class": "Rule", "name": "Authorization: what every debit authorization must satisfy", "statement": "Whatever the SEC code, an authorization must be recognizable as an authorization, set out clear and understandable terms, and tell the Receiver how, and with how much notice, to revoke it with the Originator. A consumer debit authorization is in writing and signed or similarly authenticated, and the Originator gives the consumer a copy. The Originator keeps the original, a copy, or for other forms a record that can be accurately reproduced, for two years after the authorization ends or is revoked, and must be able to produce it when its ODFI asks. The sources read give no general deadline for producing it. [Unverified]", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.ppd", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.web", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.tel", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.tompkins-originating-ach-quick-reference", "section": "Authorization", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-importance-compliant-ach-authorizations", "section": "authorization requirements; read 2026-09-19", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-web-proof-of-authorization-2022", "section": "C. Information Retention, citing Article Two, Subsection 2.3.2.7", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nicolet-ach-quick-reference-guide", "section": "Consumer Debit Authorizations", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.consumer-law-authorisation-for-a-recurring-debit-must-be", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Nacha's WEB proof of authorization paper (2022) and its 2025-11-03 article, and two bank guides for Originators, read 2026-09-19; the Nacha Operating Rules text was not consulted, and where the Nacha paper cites a rule subsection the record repeats the cite without having read it.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from the public sources its sourced_from links name; no rule change identified after the date given.", "source_edition": "Nacha public documents read 2026-09-19; bank guides undated, read 2026-09-19; Nacha Operating Rules not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.tompkins-originating-ach-quick-reference", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that an authorization must be readily identifiable, state clear terms, provide a revocation method, be signed or authenticated for a consumer debit, and be retained by the Originator for two years after termination or revocation with a copy given to the Receiver." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:mandate.consumer-debit-authorization", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:mandate.tel-debit-authorization", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:mandate.web-debit-authorization", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.authorization-ccd-ctx", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.authorization-ppd", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.authorization-tel", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.authorization-web", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.authorization-ppd", "id": "rule.authorization-ppd", "rail": "us-ach", "class": "Rule", "name": "Authorization for PPD entries", "statement": "A PPD debit to a consumer needs a written authorization, clear and recognizable as an ACH debit authorization, that the consumer signs or similarly authenticates. A PPD credit, such as payroll direct deposit, needs an authorization that is recognizable and clear, but it does not have to be in writing; banks still recommend a written direct deposit form that also allows adjusting debits.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.ppd", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.tompkins-originating-ach-quick-reference", "section": "Originating PPD Entries", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nicolet-ach-quick-reference-guide", "section": "ACH Authorizations; Standard Entry Class (SEC) Code table, PPD", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.authorization-general-requirements", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Nacha's WEB proof of authorization paper (2022) and its 2025-11-03 article, and two bank guides for Originators, read 2026-09-19; the Nacha Operating Rules text was not consulted, and where the Nacha paper cites a rule subsection the record repeats the cite without having read it.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from the public sources its sourced_from links name; no rule change identified after the date given.", "source_edition": "Nacha public documents read 2026-09-19; bank guides undated, read 2026-09-19; Nacha Operating Rules not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.tompkins-originating-ach-quick-reference", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that a PPD debit needs a written, signed authorization with clear terms while a PPD credit needs only a clear, identifiable authorization that is not required to be in writing." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:mandate.consumer-debit-authorization", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.authorization-tel", "id": "rule.authorization-tel", "rail": "us-ach", "class": "Rule", "name": "Authorization for TEL entries: oral, by phone, recorded or confirmed", "statement": "A TEL debit rests on a consumer's oral authorization over the phone, allowed only where the Originator already has a relationship with the consumer or the consumer placed the call. The Originator must make plain that an ACH debit is being authorized and get the consumer's explicit agreement. The terms captured must cover what is debited (amount, account, consumer name), when (the date, or for recurring debits the start, number or frequency), the date of the authorization, and a phone number for questions answered in business hours; a single entry authorization also says it covers one debit. For a single debit the Originator either records the call or sends written confirmation before settlement; for recurring debits it records the call and sends written confirmation before the first settlement. It keeps the recording or confirmation for two years (for recurring debits, from termination or revocation), and uses commercially reasonable steps to verify the consumer's identity and that the routing number is valid.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.tel", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.tompkins-originating-ach-quick-reference", "section": "Originating TEL Entries: obligations, warranties and minimum information", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nicolet-ach-quick-reference-guide", "section": "Standard Entry Class (SEC) Code table, TEL", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.authorization-general-requirements", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Nacha's WEB proof of authorization paper (2022) and its 2025-11-03 article, and two bank guides for Originators, read 2026-09-19; the Nacha Operating Rules text was not consulted, and where the Nacha paper cites a rule subsection the record repeats the cite without having read it.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from the public sources its sourced_from links name; no rule change identified after the date given.", "source_edition": "Nacha public documents read 2026-09-19; bank guides undated, read 2026-09-19; Nacha Operating Rules not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.tompkins-originating-ach-quick-reference", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the existing-relationship-or-consumer-initiated-call condition, the required minimum content for single and recurring oral authorizations, the recording or written confirmation timing before settlement, the two year retention periods, and the commercially reasonable identity and routing number verification duties." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:mandate.tel-debit-authorization", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.authorization-web", "id": "rule.authorization-web", "rail": "us-ach", "class": "Rule", "name": "Authorization for WEB debits: online, authenticated, provable", "statement": "A WEB debit rests on a written authorization the consumer gives over the internet or a wireless network, similarly authenticated rather than signed on paper. On top of the general authorization duties, the Originator warrants that it uses commercially reasonable authentication to verify the consumer's identity (the Nacha paper cites Subsection 2.5.17.5), commercially reasonable steps to confirm the routing number is valid, account validation within its fraud screening, and an annual audit of the security protecting the consumer financial data it holds. The rules prescribe no wording or layout. Nacha's industry practices paper suggests the online authorization show express consent to the debit, the amount or how it is set, the date or frequency, the account and routing numbers, and, for recurring or advance scheduled debits, how to revoke. To prove it later the Originator keeps the authorization and a record of the process that tied it to the consumer, such as login time and IP address; a screenshot of the terms alone does not make that link.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.web", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.tompkins-originating-ach-quick-reference", "section": "Originating WEB Entries: obligations and Originator warranties 1 to 4", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-web-proof-of-authorization-2022", "section": "Understanding the Importance of Authorization and Authentication; B. Originator Considerations; C. Information Retention; Common Industry Practices", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nicolet-ach-quick-reference-guide", "section": "Standard Entry Class (SEC) Code table, WEB", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.authorization-general-requirements", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.web-debit-account-validation", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Nacha's WEB proof of authorization paper (2022) and its 2025-11-03 article, and two bank guides for Originators, read 2026-09-19; the Nacha Operating Rules text was not consulted, and where the Nacha paper cites a rule subsection the record repeats the cite without having read it.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from the public sources its sourced_from links name; no rule change identified after the date given.", "source_edition": "Nacha public documents read 2026-09-19; bank guides undated, read 2026-09-19; Nacha Operating Rules not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-web-proof-of-authorization-2022", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the Subsection 2.5.17.5 authentication warranty, the suggested authorization content, and that a screenshot of the authorization terms alone does not establish the link to the accountholder that login timestamp and IP address records can support." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:mandate.web-debit-authorization", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.consumer-law-a-returned-payment-fee-is-its-own-debit", "id": "rule.consumer-law-a-returned-payment-fee-is-its-own-debit", "rail": "us-ach", "class": "Rule", "name": "A returned payment fee is its own debit", "statement": "When a payment comes back unpaid and the payee then collects a fee for it electronically out of the consumer's account, that fee is an electronic fund transfer in its own right and needs the consumer's own authorization, which is given when the consumer is told the amount of the fee, or how it will be worked out where the amount turns on something still to happen, and goes ahead anyway. What the consumer's own bank charges for returning the item is outside this: the authorization duty falls on whoever sends the fee as an entry, not on the account holding institution.", "rests_on": "law", "facet": "consumer-law", "applies_to": { "direction": "debit", "account_type": "consumer", "transaction_types": [], "excludes": [], "text": "a fee a payee collects electronically from a consumer account after a payment or check was returned unpaid" }, "relations": [ { "type": "sourced_from", "to": "us-ach:src.cfpb-reg-e-interpretations-coverage", "section": "comments 3(b)(3)-1, 3(b)(3)-2 and 3(b)(3)-3 on returned item fees and the notice that authorises them, and comment 3(c)(1)-1 on a fee charged after a re-presented check, read 2026-09-20", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R01", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The CFPB's Official Interpretations to 12 CFR 1005.3, read 2026-09-20. The Bureau's page does not say what a bank may charge its own customer for an insufficient funds return, and this record makes no claim about that.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "The comments carry no date of their own on the Bureau's page, so this is recorded as long-standing against the current version read on 2026-09-20.", "source_edition": "CFPB Official Interpretations to 12 CFR 1005.3, current version as read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.cfpb-reg-e-interpretations-coverage", "checked_on": "2026-09-20", "checked_by": "validator-us-ach-core-2026-09-20", "notes": "Confirms the duty to obtain a consumer's authorization to collect a returned-item fee by EFT falls only on the person initiating that EFT, not the account-holding institution; that authorization is given when the consumer receives notice of the fee amount or, where it cannot yet be calculated, a description of how it will be determined, and goes forward with the underlying transaction." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.consumer-law-authorisation-for-a-recurring-debit-must-be", "id": "rule.consumer-law-authorisation-for-a-recurring-debit-must-be", "rail": "us-ach", "class": "Rule", "name": "Authorisation for a recurring debit must be written", "statement": "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.", "rests_on": "law", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "us-ach:src.reg-e-12-cfr-1005", "section": "1005.10(b), read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:consumer-law by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. The typed parameters and the links other than sourced_from were added by the migration from the line's own words and are unchecked.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:consumer-law by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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": "us-ach:src.reg-e-12-cfr-1005", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:consumer-law, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:mandate.consumer-debit-authorization", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:mandate.web-debit-authorization", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.authorization-general-requirements", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.consumer-law-credit-as-of-the-day-funds-arrive", "id": "rule.consumer-law-credit-as-of-the-day-funds-arrive", "rail": "us-ach", "class": "Rule", "name": "Credit as of the day funds arrive", "statement": "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.", "rests_on": "law", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "us-ach:src.reg-e-12-cfr-1005", "section": "1005.10(a)(3), read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:consumer-law by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:consumer-law by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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": "us-ach:src.reg-e-12-cfr-1005", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:consumer-law, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:state.posted", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.consumer-law-government-benefit-accounts-are-inside-the", "id": "rule.consumer-law-government-benefit-accounts-are-inside-the", "rail": "us-ach", "class": "Rule", "name": "Government benefit accounts are inside the regime", "statement": "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.", "rests_on": "law", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "us-ach:src.reg-e-12-cfr-1005", "section": "1005.15, with the account definitions at 1005.2(b), read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:consumer-law by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:consumer-law by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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": "us-ach:src.reg-e-12-cfr-1005", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:consumer-law, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.consumer-law-no-forcing-a-consumer-onto-the-rail", "id": "rule.consumer-law-no-forcing-a-consumer-onto-the-rail", "rail": "us-ach", "class": "Rule", "name": "No forcing a consumer onto the rail", "statement": "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.", "rests_on": "law", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "us-ach:src.reg-e-12-cfr-1005", "section": "1005.10(e), read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:consumer-law by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:consumer-law by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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": "us-ach:src.reg-e-12-cfr-1005", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:consumer-law, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.consumer-law-notice-that-an-incoming-credit-arrived", "id": "rule.consumer-law-notice-that-an-incoming-credit-arrived", "rail": "us-ach", "class": "Rule", "name": "Notice that an incoming credit arrived", "statement": "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.", "rests_on": "law", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "us-ach:src.reg-e-12-cfr-1005", "section": "1005.10(a)(1) and (a)(2), read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:consumer-law by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:consumer-law by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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": "us-ach:src.reg-e-12-cfr-1005", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:consumer-law, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.consumer-law-the-error-clock", "id": "rule.consumer-law-the-error-clock", "rail": "us-ach", "class": "Rule", "name": "The error clock", "statement": "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.", "rests_on": "law", "facet": "consumer-law", "parameters": { "time_window": { "count": 60, "unit": "calendar_day", "from": "statement", "text": "60 days from the statement that first showed the item" } }, "relations": [ { "type": "sourced_from", "to": "us-ach:src.reg-e-12-cfr-1005", "section": "1005.11(b)(1)(i), 1005.11(c)(1) to (c)(3), read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "us-ach:exc.reg-e-error-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:consumer-law by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. The typed parameters and the links other than sourced_from were added by the migration from the line's own words and are unchecked.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:consumer-law by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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": "us-ach:src.reg-e-12-cfr-1005", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:consumer-law, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:state.recredited-under-regulation-e", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.consumer-law-the-stop-payment-right", "id": "rule.consumer-law-the-stop-payment-right", "rail": "us-ach", "class": "Rule", "name": "The stop payment right", "statement": "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.", "rests_on": "law", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "us-ach:src.reg-e-12-cfr-1005", "section": "1005.10(c), read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:consumer-law by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:consumer-law by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing. Merged 2026-09-20: us-ach:rule.refund-stopping-a-debit-before-it-happens stated the same Regulation E stop payment right, the same three business days and the same 14 day written confirmation from the same source at the same section, and was deleted; the us-ach refund fact that listed it now lists this record. The two were equally sourced, one corroboration each against the same paragraph, and this record was kept because three Mandates, a decision-points Rule and the us-ach competency bank already name it. Merged 2026-09-20: us-ach:rule.decision-points-whether-to-require-written-confirmation-of-a stated the written confirmation half of this rule, from the same Regulation E section at 1005.10(c)(2), and was deleted; the us-ach decision-points fact that listed it now lists this record. This record already states that the bank may require the oral order in writing within 14 days and that the order lapses without it, so nothing was lost. The deleted record's corroboration recorded a check of 1005.10(c)(2), which lets an institution require written confirmation of an oral stop payment order within fourteen days and ends the oral order's effect after fourteen days without it. With the merge of us-ach:rule.refund-stopping-a-debit-before-it-happens on the same day, three records for one rule became one, listed by the consumer-law, refund and decision-points facts.", "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": "us-ach:src.reg-e-12-cfr-1005", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:consumer-law, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:mandate.consumer-debit-authorization", "type": "revoked_via", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:mandate.tel-debit-authorization", "type": "revoked_via", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:mandate.web-debit-authorization", "type": "revoked_via", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.decision-points-blocking-or-filtering-incoming-debits", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.consumer-law-warning-when-the-amount-changes", "id": "rule.consumer-law-warning-when-the-amount-changes", "rail": "us-ach", "class": "Rule", "name": "Warning when the amount changes", "statement": "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.", "rests_on": "law", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "us-ach:src.reg-e-12-cfr-1005", "section": "1005.10(d), read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:consumer-law by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:consumer-law by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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": "us-ach:src.reg-e-12-cfr-1005", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:consumer-law, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:mandate.consumer-debit-authorization", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:mandate.web-debit-authorization", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.consumer-law-what-is-covered", "id": "rule.consumer-law-what-is-covered", "rail": "us-ach", "class": "Rule", "name": "What is covered", "statement": "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.", "rests_on": "law", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "us-ach:src.reg-e-12-cfr-1005", "section": "1005.3(a) and 1005.2(b)(1) and (3), read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:consumer-law by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:consumer-law by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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": "us-ach:src.reg-e-12-cfr-1005", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:consumer-law, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.iat-one-code-consumer-and-business", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.contest-window-2-banking-days", "id": "rule.contest-window-2-banking-days", "rail": "us-ach", "class": "Rule", "name": "Contested dishonored return: 2 banking days after the dishonor settles", "statement": "An RDFI that contests or corrects a dishonored return must send the contested dishonored return to the ACH Operator within 2 banking days after the settlement date of the dishonored return.", "rests_on": "rule", "facet": "return", "parameters": { "time_window": { "count": 2, "unit": "banking_day", "from": "settlement_date", "text": "2 banking days after the settlement date of the dishonored return" } }, "relations": [ { "type": "part_of", "to": "us-ach:exc.contested-dishonored-return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "section": "heading to the contested dishonored return codes", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "section": "contested dishonored returns, page 11", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.bank-of-north-dakota-ach-overview-2024", "section": "ACH contested/corrected dishonored return reason codes", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Three independent public guides (CBS Bank, Jefferson Bank, Bank of North Dakota) state the same window; read 2026-09-19. The Nacha Operating Rules were 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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that an RDFI contesting or correcting a dishonored return must transmit the contested dishonored return to the ACH Operator within two banking days after the settlement date of the dishonored return." }, { "source": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that the RDFI must respond within two banking days of the settlement date of the dishonored return, whether contesting timeliness or correcting return information." }, { "source": "us-ach:src.bank-of-north-dakota-ach-overview-2024", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that ACH dishonored returns may be contested within two banking days if the dishonored return was inaccurate or untimely." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:exc.contested-dishonored-return", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.dishonor-contested", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.return-dishonored", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R71", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R72", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R73", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R74", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R75", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R76", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R77", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.contested-dishonor-ends-the-network-dispute", "id": "rule.contested-dishonor-ends-the-network-dispute", "rail": "us-ach", "class": "Rule", "name": "A proper contest ends the dispute inside the network", "statement": "When an RDFI contests a dishonored return on time and without errors, the ODFI has to accept it. The ACH Network offers no further round; any remaining disagreement between the banks is settled outside it.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "section": "contested dishonored returns, page 11", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.return-disputing-a-return-through-the-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Jefferson Bank Obligations of Originators (March 2022), read 2026-09-19. One source; the Nacha Operating Rules were not consulted. Operating Circular 4 paragraph 15.1, cited by the linked Rule, describes the operator's side of the same sequence.", "confidence": "low" }, "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": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms an RDFI must respond to a dishonored return within two banking days of its settlement date and, if the RDFI properly contests it on time and without error, the ODFI must accept the entry and resolve any further dispute outside the ACH Network." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:exc.contested-dishonored-return", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.dishonor-contested", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R71", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R72", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R73", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R74", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R75", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R76", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R77", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.decision-points-blocking-or-filtering-incoming-debits", "id": "rule.decision-points-blocking-or-filtering-incoming-debits", "rail": "us-ach", "class": "Rule", "name": "Blocking or filtering incoming debits", "statement": "An account holder can instruct its bank to turn away entries presented against a named account before they post. A block turns them all away and sends them back to the originator with nothing for the customer to do. A filter lets some through: the customer names the originators it will accept, and a bank's service may let it key that on the originating company identification, on the standard entry class code, on whether the entry is a debit or a credit, and on a ceiling amount. Anything that does not match lands on a daily exception list that the customer works through by the bank's deadline, and what the customer does not decide in time goes back by default. The two run separately for debits and for credits, so an account can be closed to debits and still take credits. A bank needs a fair chance to act before an instruction bites, and it cannot recall what has already posted. Payees who expect to meet these controls publish the company identification their payers should register with the bank.", "rests_on": "practice", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "us-ach:src.androscoggin-ach-block-filter-appendix-2021-07", "section": "sections 2.1 and 3.1 on the block election for debits and credits, 3.2 on the filter election and the daily exception listing, 3.3 on whitelisting by company identification, SEC code, entry type or maximum amount, 4.1 to 4.3 on the pay and return decisions and the return default, and 5.5 and 5.6 on the bank needing a reasonable opportunity to act and not stopping what has posted, read 2026-09-20", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.fhb-ach-debit-block-2024-10-07", "section": "the page's description of naming authorised entities and blocking and returning everything else, read 2026-09-20", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nys-courts-echeck-origination-numbers", "section": "the instruction to give the payer's bank the payee's originating company identification where the bank uses ACH blocks or filters, read 2026-09-20", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.receiver", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.consumer-law-the-stop-payment-right", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "One bank's published block and filter contract, a second bank's public description of the same product, and a payee's instruction to its payers, all read 2026-09-20 and all on different hosts. This is a bank service, not a network rule, which is why rests_on is practice: what a given bank offers, which fields it matches on and when its deadline falls are that bank's own terms, and the corpus states no deadline of its own. [Unverified] No source read here says whether a consumer account can be given the same controls; all three describe a business or organisation account.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Block and filter services predate every source read here and none of them dates the practice, so it is recorded as long-standing.", "source_edition": "Androscoggin Bank ACH Block and Filter Service Appendix, form AB 711 revision 7/2021; First Hawaiian Bank page posted 2024-10-07; New York State Unified Court System eCheck page, undated; all read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.androscoggin-ach-block-filter-appendix-2021-07", "checked_on": "2026-09-20", "checked_by": "validator-us-ach-core-2026-09-20", "notes": "Confirms a block returns all incoming entries to the originator with no customer action, a filter reports unmatched entries as exceptions the customer clears by a bank deadline with unresolved ones defaulting to return, the whitelist runs on company ID, SEC code, entry type or a dollar ceiling, credit and debit elections are set separately, and the bank needs a reasonable chance to act and cannot undo an item already posted." }, { "source": "us-ach:src.nys-courts-echeck-origination-numbers", "checked_on": "2026-09-20", "checked_by": "validator-us-ach-core-2026-09-20", "notes": "Confirms a payee that expects to be let through an account holder's block or filter publishes the originating company ID for the payer to register with its own bank." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.return-what-a-blocked-debit-comes-back-as", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.decision-points-what-a-bank-can-cap-in-operator-monitoring", "id": "rule.decision-points-what-a-bank-can-cap-in-operator-monitoring", "rail": "us-ach", "class": "Rule", "name": "What a bank can cap in the operator's monitoring", "statement": "The operator sells an originating bank a monitoring service in which the bank sets its own cumulative debit and credit caps, keyed either to a routing number on its own or to a routing number together with named company identifications, matched character for character. The bank picks the period the totals build over: a processing day that resets at 3:01 a.m. ET, or a span of days that measures today's value against the credits of the previous two days and the debits of the previous three. A batch over a cap pends, the named contacts are emailed, and the bank releases or rejects it on screen, with an end of day default kept for extraordinary cases. Where the bank monitors by company identification it chooses whether an identification it never defined pends too or passes untouched. The service reaches every batch the operator itself processes, whatever route or software brought it in, and leaves returns out. A receiving bank has a separate service that alerts, rather than caps, on criteria it builds from fields of the incoming file, batch and entry, with file and batch alerts arriving as the file is released and entry alerts at the close of the processing day.", "rests_on": "practice", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-fedach-risk-origination-monitoring", "section": "the caps and how they are keyed, the process day and exposure day accumulation, the pend and email on a cap breach, the choice between pending and passing an undefined company identification, and the exclusion of returns, read 2026-09-20", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-fedach-risk-rdfi-alert", "section": "what the receiving bank's alert service covers, who may subscribe, the fields alert criteria are built from, and when file, batch and entry alerts are sent, read 2026-09-20", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.ach-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.limits-the-limit-a-sender-actually-hits", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The operator's own FedACH Risk Origination Monitoring Service and FedACH Risk RDFI Alert Service pages, read 2026-09-20. Neither page names a dollar figure or an item count of its own: every threshold is one the subscribing bank sets, so this record states none. rests_on is practice because these are services a bank buys, not obligations the rules impose.", "confidence": "medium" }, "currency": { "effective_since": "See source edition", "effective_to": null, "effective_note": "Both service pages are undated, so the read date stands for the edition and no start date is claimed.", "source_edition": "FedACH Risk Origination Monitoring Service and FedACH Risk RDFI Alert Service pages as read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.frb-fedach-risk-origination-monitoring", "checked_on": "2026-09-20", "checked_by": "validator-us-ach-core-2026-09-20", "notes": "Confirms the service lets an ODFI set cumulative debit and credit caps keyed by RTN alone or by RTN and Company ID matched exactly, choose a process day that resets at 3:01 a.m. ET or exposure days comparing today against the prior two days of credits and three days of debits, choose between pending all batches for undefined Company IDs or passing them untouched, set an end-of-day default for extraordinary cases, exclude returns from the service, and release or reject pended batches on FedLine screens." }, { "source": "us-ach:src.frb-fedach-risk-rdfi-alert", "checked_on": "2026-09-20", "checked_by": "validator-us-ach-core-2026-09-20", "notes": "Confirms the alert service is available to any RDFI receiving FedACH transactions and builds alert criteria from file, batch and entry fields, that batch and file alerts go out nearly simultaneously with the release of the file, and that entry-level alerts compare against criteria at the close of the FedACH processing day." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.limits-the-odfi-sets-an-exposure-limit-on-its-originator", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.decision-points-what-a-false-positive-is-on-a-sanctions-screen", "id": "rule.decision-points-what-a-false-positive-is-on-a-sanctions-screen", "rail": "us-ach", "class": "Rule", "name": "What a false positive is on a sanctions screen", "statement": "A false positive is an entry that looks at first like a match against the sanctions list and turns out, once looked into, to involve somebody other than the listed party. Working that out is the point of the screen, and the rules leave room for it: an entry carrying a positive indicator may not simply be returned to be rid of it, it has to be handled as the sanctions rules require, and the receiving bank is allowed the time to investigate a possible violation rather than being forced to decide inside the ordinary return window. Where the entry is suspect the bank is not to post it or release the funds until it has cleared the question, and a bank that screens only after crediting the account has made its own position considerably worse.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-2021-03-09", "section": "question 34 on what a false positive is, question 35 on not returning an entry merely because the indicator is positive, question 39 on the time the rules allow to investigate, and questions 16 and 33 on posting and screening order, read 2026-09-20", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.participants-gateway-screening-does-not-move-the-duty", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R90", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Nacha's IAT FAQs revised 2021-03-09, read 2026-09-20. The FAQ names the rules subsection that gives the RDFI time to investigate; the Operating Rules themselves were not read. [Unverified] No source read here says how long that time runs or what a bank does with the entry while it runs.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "The FAQ dates neither the definition nor the handling rule, so this is recorded as long-standing against the 2021-03-09 revision read.", "source_edition": "Nacha, International ACH Transactions FAQs, revised 2021-03-09, read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-iat-faqs-2021-03-09", "checked_on": "2026-09-20", "checked_by": "validator-us-ach-core-2026-09-20", "notes": "Confirms question 34's definition of a false positive, question 35's statement that a positive indicator cannot simply be returned and must be handled per OFAC requirements, question 39's statement that the rules give the RDFI time to investigate a potential violation, question 16 on withholding fund availability while a suspect item is cleared, and question 33 on the added OFAC risk of screening only after crediting the account." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.decision-points-where-to-set-the-fraud-thresholds", "id": "rule.decision-points-where-to-set-the-fraud-thresholds", "rail": "us-ach", "class": "Rule", "name": "Where to set the fraud thresholds", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-fraud-monitoring-phase-1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-fraud-monitoring-phase-2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:decision-points by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "2026-03-20", "effective_to": null, "effective_note": "Split out of us-ach:decision-points by the 2026-09 Orca Core migration; no rule change identified. The line itself dates this from 2026-03-20.", "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, "corroboration": [ { "source": "us-ach:src.nacha-fraud-monitoring-phase-1", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms Phase 1, effective March 20, 2026, requires all ODFIs and non-consumer Originators, Third-Party Service Providers and Third-Party Senders above the 2023 volume threshold, and RDFIs above the 2023 receipt threshold, to establish risk based processes and procedures without prescribing specific baselines or triggers." }, { "source": "us-ach:src.nacha-fraud-monitoring-phase-2", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the rules require a risk based approach, letting each party set its own baselines and triggers, and expressly state that the rules do not prescribe specific processes or procedures." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.decision-points-whether-a-consumers-claim-is-an-error", "id": "rule.decision-points-whether-a-consumers-claim-is-an-error", "rail": "us-ach", "class": "Rule", "name": "Whether a consumer's claim is an error", "statement": "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.", "rests_on": "law", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "us-ach:src.reg-e-12-cfr-1005", "section": "1005.11(b)(2), 1005.11(c)(1) and 1005.11(c)(2)(i), read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "us-ach:exc.reg-e-error-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:decision-points by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. The typed parameters and the links other than sourced_from were added by the migration from the line's own words and are unchecked.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:decision-points by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.reg-e-12-cfr-1005", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the ten business day period to determine whether an error occurred under 1005.11(c)(1), the ten business day written confirmation window for an oral notice under 1005.11(b)(2), and the fifty dollar cap on withholding from a provisional credit where the institution has a reasonable basis to believe the transfer was unauthorized and has met 1005.6(a), under 1005.11(c)(2)(i)." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.decision-points-whether-a-description-is-true", "id": "rule.decision-points-whether-a-description-is-true", "rail": "us-ach", "class": "Rule", "name": "Whether a description is true", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-company-entry-descriptions", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "section": "upcoming revisions section", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:decision-points by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "2026-03-20", "effective_to": null, "effective_note": "Split out of us-ach:decision-points by the 2026-09 Orca Core migration; no rule change identified. The line itself dates this from 2026-03-20.", "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, "corroboration": [ { "source": "us-ach:src.nacha-company-entry-descriptions", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the rule adding PURCHASE as a standard company entry description states the ODFI has no obligation to verify the presence or accuracy of the word as a description of purpose." }, { "source": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the new PURCHASE company entry description and states the ODFI has no obligation to verify the presence or accuracy of the word as a description of purpose." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.decision-points-whether-a-reversal-was-proper", "id": "rule.decision-points-whether-a-reversal-was-proper", "rail": "us-ach", "class": "Rule", "name": "Whether a reversal was proper", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-reversals-and-enforcement", "section": "reversals rule effective 2021-06-30, read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:decision-points by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "2021-06-30", "effective_to": null, "effective_note": "Split out of us-ach:decision-points by the 2026-09 Orca Core migration; no rule change identified. The line itself dates this from 2021-06-30.", "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, "corroboration": [ { "source": "us-ach:src.nacha-reversals-and-enforcement", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:decision-points, whose check against this source confirmed this detail line." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.decision-points-whether-an-entry-breaches-sanctions-obligations", "id": "rule.decision-points-whether-an-entry-breaches-sanctions-obligations", "rail": "us-ach", "class": "Rule", "name": "Whether an entry breaches sanctions obligations", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-sanctions-compliance-return-code", "section": "effective 2028-03-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:decision-points by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "2028-03-17", "effective_to": null, "effective_note": "Split out of us-ach:decision-points by the 2026-09 Orca Core migration; no rule change identified. The line itself dates this 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, "corroboration": [ { "source": "us-ach:src.nacha-sanctions-compliance-return-code", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms R90 will support an RDFI's decision to return an entry in compliance with sanctions obligations, effective March 17, 2028, and that OFAC rarely instructs an RDFI directly to return an entry." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.iat-ofac-hold-before-posting", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-ofac-screening-duties", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.decision-points-whether-funds-appear-before-settlement", "id": "rule.decision-points-whether-funds-appear-before-settlement", "rail": "us-ach", "class": "Rule", "name": "Whether funds appear before settlement", "statement": "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.", "rests_on": "practice", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-abcs-of-ach", "section": "standard industry practices section, read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:decision-points by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:decision-points by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.nacha-abcs-of-ach", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms some banks and credit unions may advance their own funds to a payroll recipient before settlement actually occurs, described as a practice of some institutions rather than a requirement." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:state.awaiting-settlement", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.decision-points-whether-the-originator-keeps-its-access", "id": "rule.decision-points-whether-the-originator-keeps-its-access", "rail": "us-ach", "class": "Rule", "name": "Whether the originator keeps its access", "statement": "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.", "rests_on": "practice", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "section": "compliance section", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:decision-points by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:decision-points by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the bank can transfer any fines it receives based on the customer's non compliance and can cancel ACH services if the customer does not correct the non compliance issue." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.decision-points-whether-to-dispute-a-return", "id": "rule.decision-points-whether-to-dispute-a-return", "rail": "us-ach", "class": "Rule", "name": "Whether to dispute a return", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraph 15.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:decision-points by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:decision-points by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:decision-points, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.decision-points-whether-to-honour-a-request-to-return", "id": "rule.decision-points-whether-to-honour-a-request-to-return", "rail": "us-ach", "class": "Rule", "name": "Whether to honour a request to return", "statement": "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.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "section": "R06 entry naming Article Two, Subsection 2.12.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "us-ach:exc.request-for-return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:decision-points by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. The typed parameters and the links other than sourced_from were added by the migration from the line's own words and are unchecked.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:decision-points by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the R06 return reason code table entry, where the ODFI requests the RDFI return an entry and, if the RDFI agrees to return it, the ODFI must indemnify the RDFI under Article Two, Subsection 2.12.3." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.dishonor-codes-exclude-iat", "id": "rule.dishonor-codes-exclude-iat", "rail": "us-ach", "class": "Rule", "name": "Dishonor and contest codes are not for IAT entries", "statement": "The domestic dishonored return codes (R61, R62, R67 to R70) and contested dishonored return codes (R71 to R77) may be used on every kind of entry except IAT. For cross-border items sent through FedGlobal, the Reserve Banks warn that a return may not be possible to dishonor under the foreign system's rules.", "rests_on": "rule", "facet": "return", "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [ "us-ach:txn.iat" ], "text": "every SEC code except IAT" }, "relations": [ { "type": "sourced_from", "to": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "section": "each dishonored and contested dishonored code description", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "Appendix G, paragraph 1(a)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.iat-no-dishonored-returns", "note": "The same exclusion stated from the other side, and neither record contains the other. That record rests on Nacha's IAT FAQs for what happens instead, that an ODFI cannot dishonor a returned IAT through the network, that an RDFI cannot contest one there, that the dispute is handled outside the ACH Network, and that no return reason code is barred from an IAT; this one names the excluded codes, R61, R62, R67 to R70 and R71 to R77, which is what the reason codes link to it for.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "CBS Bank quick reference (March 2025) for the code usage; Operating Circular 4 (effective 2026-01-05) Appendix G for cross-border items; both read 2026-09-19. How an IAT return is disputed instead was not found and is left to the IAT records.", "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that the dishonored and contested dishonored return reason codes each carry a description saying they may be used for all entries except IAT." }, { "source": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms Appendix G paragraph 1(a), that foreign law and payment system rules applying to a cross border ACH item can produce different outcomes than domestic rules, including that a returned item may not be able to be dishonored." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.iat-no-dishonored-returns", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R61", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R62", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R67", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R68", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R69", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R70", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R71", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R72", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R73", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R74", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R75", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R76", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R77", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.dishonor-window-5-banking-days", "id": "rule.dishonor-window-5-banking-days", "rail": "us-ach", "class": "Rule", "name": "Dishonored return: 5 banking days after the return settles", "statement": "An ODFI that dishonors a return must send the dishonored return to its ACH Operator within 5 banking days after the settlement date of the return entry. The clock runs from the return, not from the original entry.", "rests_on": "rule", "facet": "return", "parameters": { "time_window": { "count": 5, "unit": "banking_day", "from": "settlement_date", "text": "5 banking days after the settlement date of the return entry" } }, "relations": [ { "type": "part_of", "to": "us-ach:exc.dishonored-return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "section": "heading to the dishonored return codes", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.commerce-bank-ach-return-noc-tran-codes-2022-11", "section": "time frame column for R61 to R70", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "section": "dishonored returns, page 11", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.bank-of-north-dakota-ach-overview-2024", "section": "ACH dishonored return reason codes", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Four independent public guides (CBS Bank, Commerce Bank, Jefferson Bank, Bank of North Dakota) state the same window; read 2026-09-19. The Nacha Operating Rules were 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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that an ODFI dishonoring a return must transmit the dishonored return to its ACH Operator within five banking days after the settlement date of the returned entry." }, { "source": "us-ach:src.commerce-bank-ach-return-noc-tran-codes-2022-11", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the five banking day window for the ODFI to transmit a dishonored return entry to the ACH Operator, measured from the settlement date of the return entry." }, { "source": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that a dishonored return must be transmitted by the ODFI within five banking days from the settlement date of the return entry." }, { "source": "us-ach:src.bank-of-north-dakota-ach-overview-2024", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that ACH return transactions may be dishonored within five banking days if the return was inaccurate or untimely." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:exc.dishonored-return", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-dishonored-return-addenda", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.return-dishonored", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R61", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R62", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R67", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R68", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R69", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R70", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R72", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.finality-ach-is-not-a-fedwire-funds-transfer-and", "id": "rule.finality-ach-is-not-a-fedwire-funds-transfer-and", "rail": "us-ach", "class": "Rule", "name": "ACH is not a Fedwire funds transfer, and Regulation J subpart B does not reach it", "statement": "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.", "rests_on": "law", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "us-ach:src.reg-j-12-cfr-210", "section": "210.26, definitions of payment order and Fedwire Funds Service, read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraph 2.1(e)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:finality by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:finality by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:finality, whose check against this source confirmed this detail line." }, { "source": "us-ach:src.reg-j-12-cfr-210", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:finality, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.finality-no-recall-by-the-sender-once-the-file-has-gone", "id": "rule.finality-no-recall-by-the-sender-once-the-file-has-gone", "rail": "us-ach", "class": "Rule", "name": "No recall by the sender once the file has gone", "statement": "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.", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraph 13.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-reversals-and-enforcement", "section": "reversals rule effective 2021-06-30", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:finality by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:finality by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing. Merged 2026-09-20: us-ach:rule.recall-no-revocation-of-a-sent-entry stated the same provision of Operating Circular 4, paragraph 13.1, and was deleted; the us-ach recall fact that listed it now lists this record. This record was kept because it carries the fuller citation, adding Nacha's reversals rule for the exception the paragraph reserves. The deleted record's corroboration recorded a check of paragraph 13.1 against Operating Circular 4, that a sending bank or prior party may not amend or revoke an item after it has been sent to a Reserve Bank except as applicable ACH rules provide.", "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": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:finality, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:state.sent-to-the-operator", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.finality-reversals-exist-and-they-are-new-entries", "id": "rule.finality-reversals-exist-and-they-are-new-entries", "rail": "us-ach", "class": "Rule", "name": "Reversals exist, and they are new entries", "statement": "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.", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-reversals-and-enforcement", "section": "reversals rule effective 2021-06-30", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "section": "reversals section", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:finality by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:finality by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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": "us-ach:src.nacha-reversals-and-enforcement", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms an erroneous entry is corrected by originating a reversing entry rather than by cancelling the original, with formatting requirements for the reversal." }, { "source": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the receiving bank is under no obligation to post a reversing debit that overdraws the account or hits a closed account, so a reversal is not a right to recover the money." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.iat-reversal-best-effort", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.sent-to-the-operator", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.finality-second-layer-article-4a-and-only-for-some", "id": "rule.finality-second-layer-article-4a-and-only-for-some", "rail": "us-ach", "class": "Rule", "name": "Second layer: Article 4A, and only for some entries", "statement": "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.", "rests_on": "law", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraphs 2.1(e) and 2.1(j)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.reg-j-12-cfr-210", "section": "210.25 appendix commentary, describing 15 U.S.C. 1693 through section 4A-108", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:finality by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:finality by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:finality, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.finality-settlement-can-also-be-refused-before-it-happens", "id": "rule.finality-settlement-can-also-be-refused-before-it-happens", "rail": "us-ach", "class": "Rule", "name": "Settlement can also be refused before it happens", "statement": "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.", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraph 10.4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:finality by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:finality by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing. Merged 2026-09-20: us-ach:rule.decision-points-whether-to-settle-at-all stated the same provision of Operating Circular 4, paragraph 10.4, and was deleted; the us-ach decision-points fact that listed it now lists this record. This record was kept because it states the provision in full: the deleted record gave only the expected shortfall as a trigger and left out suspension of payment and closure, which this record carries.", "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": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:finality, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:state.awaiting-settlement", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.finality-settlement-can-be-unwound-the-next-morning", "id": "rule.finality-settlement-can-be-unwound-the-next-morning", "rail": "us-ach", "class": "Rule", "name": "Settlement can be unwound the next morning", "statement": "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.", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraph 11.1(b)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:finality by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:finality by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:finality, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:state.settled", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.settlement-unwound", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.finality-the-moment-settlement-is-final-for-a-credit", "id": "rule.finality-the-moment-settlement-is-final-for-a-credit", "rail": "us-ach", "class": "Rule", "name": "The moment settlement is final for a credit", "statement": "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.", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraph 11.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:finality by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:finality by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:finality, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:state.settled", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.finality-the-practical-window-returns-run-in-days-not", "id": "rule.finality-the-practical-window-returns-run-in-days-not", "rail": "us-ach", "class": "Rule", "name": "The practical window: returns run in days, not seconds", "statement": "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.", "rests_on": "rule", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-reversals-and-enforcement", "section": "reversals rule effective 2021-06-30, which states the R11 60 day and R17 2 day return time frames", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "section": "return time frame table and 24 hour exception note", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:finality by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:finality by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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": "us-ach:src.nacha-reversals-and-enforcement", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms an RDFI may return an improper reversal to a consumer account using R11 within a sixty calendar day window and to a non consumer account using R17 within a two banking day window, both measured from the settlement date of the improper reversal." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:state.funds-available", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.settled", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.finality-third-layer-the-consumers-claim-runs-on-its-own", "id": "rule.finality-third-layer-the-consumers-claim-runs-on-its-own", "rail": "us-ach", "class": "Rule", "name": "Third layer: the consumer's claim runs on its own clock", "statement": "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.", "rests_on": "law", "facet": "finality", "relations": [ { "type": "sourced_from", "to": "us-ach:src.reg-e-12-cfr-1005", "section": "1005.11(b)(1)(i) and 1005.11(c), read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:finality by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:finality by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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": "us-ach:src.reg-e-12-cfr-1005", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms 1005.11(b)(1)(i), the sixty day window from the periodic statement on which the alleged error is first reflected for a consumer notice of error to trigger the section, and 1005.11(c), the resulting investigation duties, independent of any ACH return deadline." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:state.recredited-under-regulation-e", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.format-addenda-indicator-and-linking", "id": "rule.format-addenda-indicator-and-linking", "rail": "us-ach", "class": "Rule", "name": "How an addenda record is tied to its entry", "statement": "An addenda record always follows the entry it belongs to. The entry's addenda record indicator says whether any follow (1) or none (0). Each addenda carries the last seven digits of its entry's trace number, and the addenda of one entry are numbered upward from 1. How many an entry may carry depends on the SEC code: a TEL entry takes none; PPD, CCD and WEB take at most one, of addenda type 05, for free text payment information; a CCD zero dollar entry must carry that one; CTX allows up to 9,999; and an ENR carries at least one and at most 9,999. A malformed addenda is returned with R25, and an addenda whose trace link does not match its entry with R27.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.tel", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.ppd", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.ccd", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.web", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.ctx", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.enr", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-ach-developer-guide-file-details", "section": "PPD, CCD, WEB, TEL Entry records and PPD, CCD, and WEB Addenda records; read 2026-09-19", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.moov-ach-file-structure", "section": "Entry Detail and Addenda Records descriptions; CTX Addenda Record; read 2026-09-19", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.treasury-green-book-2025-03", "section": "Chapter 1, ENR: at least one and up to 9,999 addenda; read 2026-09-19", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R25", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R27", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Nacha's public developer guide, the moov-io/ach documentation and the Green Book, read 2026-09-19; the Nacha Operating Rules were not consulted. The R25 and R27 links rest on those code records.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from the public sources its sourced_from links name, for the file format gap (OC-5); no rule change identified.", "source_edition": "Nacha's public ACH Guide for Developers read 2026-09-19; moov-io/ach documentation read 2026-09-19; Green Book edition published 2025-03; Nacha Operating Rules and Nacha's technical guide not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-ach-developer-guide-file-details", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the addenda record indicator values of 0 and 1, that an addenda carries the last seven digits of its entry trace number, that addenda sequence numbers start at 1, that the PPD, CCD and WEB addenda type is 05 for payment related information, and that a CCD zero dollar entry must carry one addenda." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.format-balanced-and-unbalanced-files", "id": "rule.format-balanced-and-unbalanced-files", "rail": "us-ach", "class": "Rule", "name": "Balanced and unbalanced files", "statement": "An unbalanced file carries only the Originator's entries, and the ODFI posts the offsetting settlement to the Originator's account itself. A balanced file also carries that offsetting entry to the Originator's settlement account, so its debits and credits net to zero. Which form the ODFI accepts is set by the ODFI; none of the public sources read says the network requires either. [Inference]", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-ach-developer-guide-file-overview", "section": "Types of Files; read 2026-09-19", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Nacha's public developer guide, read 2026-09-19. That the choice is the ODFI's is inferred from the guide saying the ODFI manages the offset account in an unbalanced file.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from the public sources its sourced_from links name, for the file format gap (OC-5); no rule change identified.", "source_edition": "Nacha's public ACH Guide for Developers read 2026-09-19; Nacha Operating Rules and Nacha's technical guide not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-ach-developer-guide-file-overview", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the definitions of an unbalanced file as one where the ODFI manages the offset account outside the file and a balanced file as one carrying that offset account within the file; does not say the network requires either form." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.format-batch-control-totals", "id": "rule.format-batch-control-totals", "rail": "us-ach", "class": "Rule", "name": "The batch control proves the batch", "statement": "Each batch closes with a control record that must agree with its header on service class code, company identification, ODFI routing number and batch number. It carries the batch's own proofs: the debit total, the credit total, the number of entry and addenda records (headers and controls are not counted), and an entry hash, which is the sum of the eight digit receiving bank routing numbers of the entries in the batch. The file control's hash and totals are in turn built from the batch controls.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-ach-developer-guide-file-details", "section": "ACH Batch Header and Trailer, batch control; ACH File Header and Trailer, file control; read 2026-09-19", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.moov-ach-file-structure", "section": "Company/Batch Control Record description; read 2026-09-19", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.format-file-header-and-control", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Nacha's public developer guide and the moov-io/ach documentation, read 2026-09-19. How a hash that overflows its field is cut down is not stated in the sources read.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from the public sources its sourced_from links name, for the file format gap (OC-5); no rule change identified.", "source_edition": "Nacha's public ACH Guide for Developers read 2026-09-19; moov-io/ach documentation read 2026-09-19; Nacha Operating Rules and Nacha's technical guide not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-ach-developer-guide-file-details", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the batch control record carries service class code, entry/addenda count, entry hash, debit and credit totals, company identification, ODFI routing number and batch number, matching the batch header fields." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.format-batch-header-holds-what-entries-share", "id": "rule.format-batch-header-holds-what-entries-share", "rail": "us-ach", "class": "Rule", "name": "The batch header holds what every entry in the batch shares", "statement": "A batch groups entries that share one set of descriptive data, and that data is written once, in the batch header: the SEC code, the company entry description, the effective entry date the Originator wants, the Originator's company name and the company identification its ODFI assigned, the ODFI's routing number and a batch number. If any of these differs, for instance a bonus run beside a salary run, or a second effective date, the entries need a batch of their own. The header also carries a service class code saying whether the batch holds credits only (220), debits only (225) or both (200); the batch control repeats that code and must match. One field, the settlement date, is left for the ACH Operator to fill in.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.ach-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-ach-developer-guide-file-overview", "section": "ACH Files, Record Overview and Service Class Codes; read 2026-09-19", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-ach-developer-guide-file-details", "section": "ACH Batch Header and Trailer; read 2026-09-19", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.moov-ach-file-structure", "section": "Company/Batch Header Record description; read 2026-09-19", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.messages-the-standard-entry-class-code", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.messages-the-description-field-is-becoming-meaningful", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.messages-reversal-is-a-field-value-not-a-message-type", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Nacha's public developer guide and the moov-io/ach documentation, read 2026-09-19; the Nacha Operating Rules were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from the public sources its sourced_from links name, for the file format gap (OC-5); no rule change identified.", "source_edition": "Nacha's public ACH Guide for Developers read 2026-09-19; moov-io/ach documentation read 2026-09-19; Nacha Operating Rules and Nacha's technical guide not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-ach-developer-guide-file-details", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the batch header carries SEC code, company entry description, effective entry date, company name, ODFI-assigned company identification and service class code, and that settlement date is inserted by the ACH Operator." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.format-blocking-and-padding", "id": "rule.format-blocking-and-padding", "rail": "us-ach", "class": "Rule", "name": "Files are built in blocks of ten records", "statement": "The file header declares a record size of 94 and a blocking factor of 10, and the file control counts blocks. When the number of records is not a multiple of ten, the last block is filled out with records made entirely of the digit 9; a file that already ends on a multiple of ten needs none. Nacha's developer guide describes the padding as part of the format and First Citizens Bank asks its originators to check it before sending, while the moov-io/ach documentation calls the padding optional; an originator should follow what its ODFI accepts.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-ach-developer-guide-file-overview", "section": "Record Overview, blocking factor paragraph; read 2026-09-19", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-ach-developer-guide-file-details", "section": "File Header record, record size and blocking factor fields; read 2026-09-19", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.first-citizens-nacha-file-specifications-2024-02", "section": "Best Practices, page 12; read 2026-09-19", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.moov-ach-file-structure", "section": "Sequence of records, note on padding; read 2026-09-19", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Nacha's public developer guide, one bank's file specification and the moov-io/ach documentation, read 2026-09-19. The sources disagree on whether padding is required; the Nacha Operating Rules, which would settle it, were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from the public sources its sourced_from links name, for the file format gap (OC-5); no rule change identified.", "source_edition": "Nacha's public ACH Guide for Developers read 2026-09-19; First Citizens Bank specification Rev 02/2024; moov-io/ach documentation read 2026-09-19; Nacha Operating Rules and Nacha's technical guide not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-ach-developer-guide-file-overview", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the 94 character record size, blocking factor of 10, and padding of a partial final block with records of 9s; the moov-io documentation separately calls that padding optional and First Citizens Bank's guide tells its originators to verify the padding before sending." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.format-cie-mte-name-and-identification", "id": "rule.format-cie-mte-name-and-identification", "rail": "us-ach", "class": "Rule", "name": "CIE and MTE entries swap the name and identification fields", "statement": "In PPD, CCD and WEB entries the identification number comes before the Receiver's name. In CIE and MTE entries the two change places: the individual's name comes first and the identification number second. In a CIE bill payment the identification number is the number the paying consumer is known by at the biller, such as the account number on the bill, which the biller needs to apply the payment. Software that reads every entry with the PPD layout puts each value in the other's field; one widely used open source library did so until 2026.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "applies_to", "to": "us-ach:txn.cie", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.mte", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.moov-ach-file-structure", "section": "CIE Entry Detail Record and MTE Entry Detail Record; read 2026-09-19", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.moov-ach-issue-1766", "section": "issue body and maintainer reply of 2026-04-02; read 2026-09-19", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-ach-developer-guide-file-details", "section": "PPD and CCD Entry and WEB and TEL Entry, for the usual order; read 2026-09-19", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Two documents from one open source project and Nacha's public developer guide for the PPD order, read 2026-09-19. No independent source for the CIE and MTE order was read. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from the public sources its sourced_from links name, for the file format gap (OC-5); no rule change identified.", "source_edition": "Nacha's public ACH Guide for Developers read 2026-09-19; moov-io/ach documentation and issue 1766 read 2026-09-19; Nacha Operating Rules and Nacha's technical guide not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.moov-ach-file-structure", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that in the CIE entry detail record field 7 (positions 40-54) holds Individual Name and field 8 (55-76) holds Individual Identification Number, the reverse order from PPD, CCD and WEB; the linked GitHub issue confirms a widely used open source library had those two fields flipped for CIE and MTE." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.format-ctx-return", "id": "rule.format-ctx-return", "rail": "us-ach", "class": "Rule", "name": "Returning a CTX entry", "statement": "A CTX entry is returned the same way as any other entry, with one return addenda carrying the return code and the original trace number. Two things differ in practice. The CTX entry detail is laid out differently from PPD and CCD: it carries a four digit count of its addenda and a receiving company name field in place of the individual name layout, so software that builds returns from the PPD layout breaks on CTX. And the remittance addenda of the forward CTX entry, up to 9,999 of them, do not come back with the return under the general rule that forward addenda are not copied. [Unverified] what the addenda count field holds on the returned CTX entry: no source read says.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.ctx", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.moov-ach-issue-1501", "section": "maintainer reply of 2024-11-08; read 2026-09-19", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.moov-ach-file-structure", "section": "CTX Entry Detail Record and CTX Addenda Record; read 2026-09-19", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.format-return-entry-construction", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "A practitioner issue and the documentation of the same open source project, read 2026-09-19; both are one source family. The Nacha Operating Rules were not consulted.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from the public sources its sourced_from links name, for the file format gap (OC-5); no rule change identified.", "source_edition": "moov-io/ach documentation and issue 1501 read 2026-09-19; Nacha Operating Rules and Nacha's technical guide not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.moov-ach-file-structure", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the CTX entry detail record carries a Number of Addenda Records field and a Receiving Company Name/ID Number field in place of the PPD individual name layout, and up to 9,999 addenda; the linked GitHub issue shows a return-building tool rejecting a CTX return addenda because it expected the PPD style addenda count, confirming that PPD-based return logic breaks on CTX." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.format-dishonored-return-addenda", "id": "rule.format-dishonored-return-addenda", "rail": "us-ach", "class": "Rule", "name": "What the addenda of a dishonored return points back to", "statement": "A dishonored return is built by the ODFI from the return it refuses, and its type 99 addenda looks back two steps. It names the dishonor reason (R61, R62 or R67 to R70), and it identifies both earlier items: the return being dishonored, by its trace number, its settlement date and its return reason code, and the forward entry, by its full 15 digit trace number and the routing number it was sent to. For R69 the addenda information field lists each field found in error as a two digit code, joined by asterisks; the fields that can be flagged are the amount, the account number, the effective date, the trace number, the transaction code, and the individual or company identification.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "us-ach:exc.dishonored-return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.moov-ach-addenda99-dishonored-source", "section": "Addenda99Dishonored fields and accepted codes; read 2026-09-19", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.treasury-green-book-2025-03", "section": "Chapter 4, Returns, D, Dishonored Returns; read 2026-09-19", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-dishonored-return-fax-form-instructions-2024-04", "section": "fields 9, 22, 24 and 25; read 2026-09-19", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R69", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R61", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.dishonor-window-5-banking-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "An open source library's source code, the Green Book and the Federal Reserve's dishonor form instructions, read 2026-09-19. Where the original trace number sits in the record is held in the source code and the paid rulebook, not here. The Nacha Operating Rules were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from the public sources its sourced_from links name, for the file format gap (OC-5); no rule change identified.", "source_edition": "Green Book edition published 2025-03; FedACH form instructions version 3.1; moov-io/ach source read 2026-09-19; Nacha Operating Rules and Nacha's technical guide not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.frb-dishonored-return-fax-form-instructions-2024-04", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the dishonored return reason code field and, for R69, the field error addenda codes 01 account number, 02 trace number, 03 dollar amount, 04 individual ID, 05 transaction code, 06 company ID and 07 effective date; the moov-io source file confirms the type 99 dishonored addenda separately carries the original entry trace number, the original receiving DFI identification, the return's own trace number and settlement date, and the original return reason code." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.format-enr-entry-codes", "id": "rule.format-enr-entry-codes", "rail": "us-ach", "class": "Rule", "name": "Transaction codes and addenda in an automated enrollment (ENR) entry", "statement": "An ENR entry, sent by an RDFI to a federal agency to sign a customer up for direct deposit, moves no money: its amount is all zeros, and for the federal agencies the Green Book covers its transaction code is the prenote credit code for checking (23) or savings (33). The account the agency is to pay into is described in the addenda, where the account type is 22 for checking or 32 for savings; a value the agency cannot use comes back as R41. An ENR carries at least one addenda, can carry up to 9,999 when all are for the same benefit program, and at least one paying agency needs alphabetic data in upper case. A returned ENR travels on the return code for a credit, 21 or 31. [Inference] from the general code table; one open source library began accepting 21 and 31 in ENR batches in 2025 after a user report.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.federal-government-agency", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.enr", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.treasury-green-book-2025-03", "section": "Chapter 1, Enrollment: ENR description, Entry Detail Record and Addenda Record; read 2026-09-19", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.commerce-bank-ach-return-noc-tran-codes-2022-11", "section": "Transaction Codes table, page 8; read 2026-09-19", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.moov-ach-issue-1672", "section": "issue body and maintainer reply of 2025-10-31; read 2026-09-19", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.first-citizens-nacha-file-specifications-2024-02", "section": "Transaction Codes, pages 12 and 13; read 2026-09-19", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R41", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R40", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.return-window-enr-agency", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The Green Book's ENR pages, a bank's code table, a second bank's specification and a practitioner issue, read 2026-09-19. The return codes rest on the general table and a library change, not on any source that states them for ENR.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from the public sources its sourced_from links name, for the file format gap (OC-5); no rule change identified.", "source_edition": "Green Book edition published 2025-03; Commerce Bank table November 2022; First Citizens Bank specification Rev 02/2024; moov-io/ach issue 1672 read 2026-09-19; Nacha Operating Rules and Nacha's technical guide not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.treasury-green-book-2025-03", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms an ENR is non-monetary, must carry at least one addenda and may carry up to 9,999 when all are for the same federal benefit program, and that a federal agency returns R41 Invalid Transaction Code when Field 3 of the addenda carries an incorrect or inappropriate transaction code; the moov-io documentation confirms the entry detail record's Number of Addenda Records and Addenda Record Indicator fields." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.format-field-fill-conventions", "id": "rule.format-field-fill-conventions", "rail": "us-ach", "class": "Rule", "name": "How fields are filled", "statement": "Text fields are written from the left and padded with spaces; number fields are written from the right, unsigned, padded with leading zeros, and amounts carry cents with no decimal point or currency sign. Code fields take upper case only. Control characters are not valid anywhere in a record.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-ach-developer-guide-file-overview", "section": "Data Specifications; read 2026-09-19", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.moov-ach-file-structure", "section": "NACHA Data Entry Specifications; read 2026-09-19", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.first-citizens-nacha-file-specifications-2024-02", "section": "Best Practices, page 12; read 2026-09-19", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.messages-character-handling-is-not-uniform-between", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Nacha's public developer guide, the moov-io/ach documentation and one bank's specification, read 2026-09-19; the Nacha Operating Rules were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from the public sources its sourced_from links name, for the file format gap (OC-5); no rule change identified.", "source_edition": "Nacha's public ACH Guide for Developers read 2026-09-19; moov-io/ach documentation read 2026-09-19; First Citizens Bank specification Rev 02/2024; Nacha Operating Rules and Nacha's technical guide not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-ach-developer-guide-file-overview", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms alphanumeric fields are left justified and space padded, numeric fields are unsigned, right justified and zero padded, and code fields take uppercase only; First Citizens Bank's file specification confirms dollar amounts carry no decimal point or currency sign." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.format-file-header-and-control", "id": "rule.format-file-header-and-control", "rail": "us-ach", "class": "Rule", "name": "A file opens with one header record and closes with one control record", "statement": "Every ACH file has exactly one header record first and one control record last, and one or more batches between them. The header says, by routing number, which institution sent the file and which one is to receive it, and dates it; a one character modifier lets the receiver tell apart two files sent on the same day, which is how duplicate files are caught. The control record restates totals for the whole file: how many batches and blocks, how many entry and addenda records, a hash, and the debit total and credit total. Those totals exist so the receiving side can prove nothing was dropped or altered. Records in the wrong order, or a mandatory record left out, get all or part of the file rejected.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-ach-developer-guide-file-overview", "section": "Record Sequence and Record Overview; read 2026-09-19", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-ach-developer-guide-file-details", "section": "ACH File Header and Trailer; read 2026-09-19", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.moov-ach-file-structure", "section": "Sequence of records and description; read 2026-09-19", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.messages-the-record-types-a-payment-uses", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.messages-the-record-line", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Nacha's public developer guide (file overview and file details pages) and the moov-io/ach file structure documentation, read 2026-09-19. The rejection consequence rests on the moov-io page alone. The Nacha Operating Rules, Appendix Three, were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from the public sources its sourced_from links name, for the file format gap (OC-5); no rule change identified.", "source_edition": "Nacha's public ACH Guide for Developers read 2026-09-19; moov-io/ach documentation read 2026-09-19; Nacha Operating Rules and Nacha's technical guide not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-ach-developer-guide-file-details", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the file header carries a File ID Modifier meant to give each file submitted on a single processing day a unique identifier for duplicate file detection, and that the file control record restates totals across the whole file." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.format-batch-control-totals", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.format-mandatory-required-optional-fields", "id": "rule.format-mandatory-required-optional-fields", "rail": "us-ach", "class": "Rule", "name": "Mandatory, required and optional fields, and who acts on a gap", "statement": "Record layouts mark each field as mandatory, required or optional, and the mark says who enforces it. A bad or missing mandatory field is one the ACH Operator itself rejects, the entry or the whole batch. A missing required field passes the operator but may leave the RDFI unable to post, so it can come back as a return. An optional field is the Originator's choice, but once filled it has to be carried back in any return, as must the discretionary data field.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "binds", "to": "us-ach:role.ach-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.moov-ach-file-structure", "section": "Field Inclusion Requirements; CIE Entry Detail Record, discretionary data; read 2026-09-19", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-dishonored-return-fax-form-instructions-2024-04", "section": "Section 3 and the mandatory, required and optional markings; read 2026-09-19", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R26", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.return-window-operator-reject", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The moov-io/ach documentation and the Federal Reserve's dishonor form instructions, which use the same three markings, read 2026-09-19; the Nacha Operating Rules were not consulted. [Unverified] against the rules' own definitions.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from the public sources its sourced_from links name, for the file format gap (OC-5); no rule change identified.", "source_edition": "moov-io/ach documentation read 2026-09-19; FedACH form instructions version 3.1; Nacha Operating Rules and Nacha's technical guide not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.moov-ach-file-structure", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the three field designations: a missing Mandatory field is rejected by the ACH Operator, a missing Required field passes the operator but can cause the RDFI to reject or return the entry, and an Optional field is the Originator's choice but must be carried back in any return." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.format-record-line-ending", "id": "rule.format-record-line-ending", "rail": "us-ach", "class": "Rule", "name": "What ends one record and starts the next", "statement": "Records have a fixed length of 94 characters, so a reader can find each record by position; the first character of each one (1, 5, 6, 7, 8 or 9) says what kind of record it is. First Citizens Bank requires every record in a file sent to it to end with a carriage return and line feed. None of the public sources read says whether the network format itself requires a separator, allows one, or forbids one, so the practical answer is the receiving bank's own file specification. [Unverified]", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.first-citizens-nacha-file-specifications-2024-02", "section": "Best Practices, page 12; read 2026-09-19", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-ach-developer-guide-file-overview", "section": "ACH Files and Record Sequence; read 2026-09-19", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.messages-the-record-line", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "One bank's file specification and Nacha's public developer guide, read 2026-09-19. That the network standard is silent on a separator is an inference from the sources read, not a statement any of them makes.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from the public sources its sourced_from links name, for the file format gap (OC-5); no rule change identified.", "source_edition": "Nacha's public ACH Guide for Developers read 2026-09-19; First Citizens Bank specification Rev 02/2024; Nacha Operating Rules and Nacha's technical guide not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-ach-developer-guide-file-overview", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms each record is identified by a single digit type code as the first character of the line; First Citizens Bank's file specification separately requires every record in a file sent to it to be fixed at 94 characters ending with carriage return and line feed, which is that bank's own file specification rather than a network requirement." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.format-return-entry-construction", "id": "rule.format-return-entry-construction", "rail": "us-ach", "class": "Rule", "name": "How a return entry is built from the original", "statement": "A return is a new entry made from the original. The RDFI copies the original batch header, entry detail and batch control, then changes what makes the return its own: a new batch number and trace number, its own routing number where the header names the originating institution, and the return transaction code matching the original's code. It attaches one return addenda (type 99) carrying the return reason code, the original entry's trace number and the routing number the entry was sent to. The forward entry's own addenda are generally not copied back; IAT is the exception, where the mandatory IAT addenda travel with the return. Fields the Originator filled, including optional and discretionary data, come back unchanged. For federal payments Treasury checks four values on every return against the original (original trace number, effective entry date, amount and individual identification number) and dishonors a return where any differs.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.treasury-green-book-2025-03", "section": "Chapter 4, Returns: B, Correct Preparation of Returns, and D, Dishonored Returns; read 2026-09-19", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.moov-ach-issue-151", "section": "comments of 2018-06-15 and 2018-12-11 on header fields and copied records; read 2026-09-19", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.moov-ach-returns-docs", "section": "Creation; read 2026-09-19", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.moov-ach-file-structure", "section": "Field Inclusion Requirements; IAT return notes; read 2026-09-19", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R27", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.messages-the-record-types-a-payment-uses", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.iat-return-addenda", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The Green Book returns chapter, a practitioner thread on the moov-io/ach project and the library's documentation, read 2026-09-19. That forward addenda are generally not copied rests on a practitioner comment quoting the Nacha rules and on the IAT notes in the moov-io/ach documentation; the Nacha Operating Rules, Appendix Four, were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from the public sources its sourced_from links name, for the file format gap (OC-5); no rule change identified.", "source_edition": "Green Book edition published 2025-03; moov-io/ach documentation and issue 151 read 2026-09-19; Nacha Operating Rules and Nacha's technical guide not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.treasury-green-book-2025-03", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that a return entry is prepared by copying the original batch header, entry detail and batch control records, and that Treasury checks the original trace number, effective entry date, amount and individual identification number on federal payment returns and dishonors a return where any of the four differs; the linked GitHub issue confirms a return is built as a new batch carrying the same values as the original with a return addenda attached." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.format-ctx-return", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.format-trace-number-assignment", "id": "rule.format-trace-number-assignment", "rail": "us-ach", "class": "Rule", "name": "Trace numbers: who assigns them and how they run", "statement": "The ODFI assigns each entry's trace number. Within a batch the numbers must rise, though they need not rise by one, and each identifies one entry uniquely within its batch and file. Because the trace number is what every later return, dishonor or inquiry matches on, a return carries the original entry's trace number in its addenda and gets a new trace number of its own.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-ach-developer-guide-file-overview", "section": "Data Specifications; read 2026-09-19", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-ach-developer-guide-file-details", "section": "PPD and CCD Entry, trace number field; read 2026-09-19", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.moov-ach-returns-docs", "section": "Creation; read 2026-09-19", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.messages-what-identifies-an-entry-afterwards", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R27", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Nacha's public developer guide and the moov-io/ach returns documentation, read 2026-09-19; the Nacha Operating Rules were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from the public sources its sourced_from links name, for the file format gap (OC-5); no rule change identified.", "source_edition": "Nacha's public ACH Guide for Developers read 2026-09-19; moov-io/ach documentation read 2026-09-19; Nacha Operating Rules and Nacha's technical guide not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-ach-developer-guide-file-overview", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms trace numbers are assigned by the ODFI and must be ascending, though not necessarily consecutive, within a batch, and uniquely identify each entry within its batch and file." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.format-transaction-codes", "id": "rule.format-transaction-codes", "rail": "us-ach", "class": "Rule", "name": "The transaction code: account type, direction and whether money moves", "statement": "Every entry carries a two digit transaction code. In the codes the sources list, a first digit of 2 means a checking account and 3 a savings account; the second digit says what the entry does: 2 a live credit and 7 a live debit, 3 and 8 a zero dollar prenotification of a credit or debit, 4 and 9 a zero dollar entry carrying remittance data (CCD and CTX only). Returns and notifications of change use codes of their own: 1 in the second digit for a credit and 6 for a debit, so a return of a checking credit (22, 23 or 24) goes back as 21, and a return of a savings debit as 36. Other non value entries reuse these codes: automated enrollment and death notification entries take the credit prenote codes (23, 33), and acknowledgements the zero dollar remittance credit codes (24, 34).", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.prenote", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.enr", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "us-ach:exc.notification-of-change", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.commerce-bank-ach-return-noc-tran-codes-2022-11", "section": "Transaction Codes table, page 8; read 2026-09-19", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-ach-developer-guide-file-overview", "section": "Transaction Codes; read 2026-09-19", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.first-citizens-nacha-file-specifications-2024-02", "section": "Transaction Codes, pages 12 and 13; read 2026-09-19", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-dishonored-return-fax-form-instructions-2024-04", "section": "field 6, Transaction Code; read 2026-09-19", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.prenote-optional-zero-dollar-entry", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "A bank's code table, Nacha's public developer guide, a second bank's specification and the Federal Reserve's dishonor form instructions, read 2026-09-19. The digit by digit reading is Orca's way of stating the table, checked against every code the sources list; loan and general ledger codes were not read.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from the public sources its sourced_from links name, for the file format gap (OC-5); no rule change identified.", "source_edition": "Nacha's public ACH Guide for Developers read 2026-09-19; Commerce Bank table November 2022; First Citizens Bank specification Rev 02/2024; FedACH form instructions version 3.1; Nacha Operating Rules and Nacha's technical guide not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.commerce-bank-ach-return-noc-tran-codes-2022-11", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the transaction code table: 22/27 checking credit/debit, 32/37 savings credit/debit, 23/28/33/38 prenotification, 24/29/34/39 zero dollar remittance for CCD and CTX only, and 21/26/31/36 as the return or NOC codes for a checking or savings credit or debit." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.hours-a-bank-closed-on-the-settlement-date", "id": "rule.hours-a-bank-closed-on-the-settlement-date", "rail": "us-ach", "class": "Rule", "name": "A bank closed on the settlement date", "statement": "Where the settlement date is not a banking day for one of the two banks, settlement still happens on that date for three of the four cases: a closed sending bank is credited on the date for debit items and debited on the date for credit items, and a closed receiving bank is credited on the date for credit items. The one variation is a debit item to a closed receiving bank, which is debited on the settlement date or, if that bank prefers, the next day with an explicit charge for the float. The return clock is treated differently: a receiving bank is not counted as having received an item made available to it on a day it was closed until its next banking day, so the deadline for returning it starts from there. Where an item names a settlement date that is not a banking day at all, settlement moves to the next banking day.", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "Appendix B sections 3.2 and 3.3, on a settlement date that is not a banking day, on settlement where the sending or receiving bank is closed, and on when a closed receiving bank is treated as having received an item for the return deadline, read 2026-09-20", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.return-window-2-banking-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Federal Reserve Banks Operating Circular 4, effective 2026-01-05, Appendix B sections 3.2 and 3.3, read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "2026-01-05", "effective_to": null, "effective_note": "The date is the effective date of the Operating Circular 4 edition read; the provision is older than this edition.", "source_edition": "Federal Reserve Banks Operating Circular 4, effective 2026-01-05, read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-20", "checked_by": "validator-us-ach-core-2026-09-20", "notes": "Confirms Appendix B 3.2 and 3.3: a settlement date that is not a banking day at all moves to the next banking day; where the sending or receiving bank is closed, a closed sending bank is credited on the date for debit items and debited on the date for credit items, a closed receiving bank is credited on the date for credit items and may take a debit item on the date or choose the next day with an explicit float charge; and a receiving bank closed on the day an item is made available is not counted as having received it until its next banking day for the return deadline." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:cal.federal-reserve-banks", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.hours-a-day-off-the-holiday-list-is-still-a-banking-day", "id": "rule.hours-a-day-off-the-holiday-list-is-still-a-banking-day", "rail": "us-ach", "class": "Rule", "name": "A day off the holiday list is still a banking day", "statement": "The Reserve Banks' banking days are every day except a closed list: Saturdays, Sundays and eleven named federal holidays, with New Year's Day, Independence Day, Veterans Day and Christmas rolling to the following Monday when they land on a Sunday. Nothing else comes off the list, so a closure announced at short notice, such as a national day of mourning, does not take the day out of the calendar by itself. The worked case is the day of mourning of 2018-12-05, for which the Board closed its own offices in Washington and said Reserve Bank payment systems would run normally.", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "Appendix B section 4.1, the list of standard holidays and the Sunday rollover, read 2026-09-20", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-day-of-mourning-2018-12-03", "section": "the announcement that Board offices in Washington would close on 2018-12-05 and that Reserve Bank payment systems would operate normally, read 2026-09-20", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frbservices-holiday-schedules", "section": "the closed dates and the Saturday and Sunday rules, and the FedACH schedule showing when processing ends before a holiday and resumes after it, read 2026-09-20", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.ach-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.hours-what-a-banking-day-is", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Operating Circular 4 Appendix B section 4.1, the Board's 2018-12-03 press release, and the operator's holiday schedule page, all read 2026-09-20. [Inference] That an ad hoc closure leaves the day a banking day follows from the list being closed and from the 2018 case going that way; no source read states the general rule in those words, and a future closure could be announced differently. An individual bank that shuts on such a day is a separate matter, handled by the Rule on a bank closed on the settlement date.", "confidence": "medium" }, "currency": { "effective_since": "2026-01-05", "effective_to": null, "effective_note": "The date is the effective date of the Operating Circular 4 edition read. The holiday list itself is long-standing and the Juneteenth entry is newer than the rest.", "source_edition": "Federal Reserve Banks Operating Circular 4, effective 2026-01-05; Federal Reserve Board press release of 2018-12-03; Federal Reserve System Holiday Schedule as read 2026-09-20", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:cal.federal-reserve-banks", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.hours-a-deadline-stated-in-hours-runs-on-the-clock", "id": "rule.hours-a-deadline-stated-in-hours-runs-on-the-clock", "rail": "us-ach", "class": "Rule", "name": "A deadline stated in hours runs on the clock", "statement": "Time on this rail is kept on a clock in Eastern time, not on a calendar of whole days. The Reserve Banks' banking day for taking in ACH items opens at 3:00 a.m. ET and closes at 2:59 a.m. ET the next calendar day, with processing and transmission running to 6:00 a.m. ET on the calendar day the receiving window ends, and different times around weekends and holidays. Deposit deadlines are likewise times of day, not day counts. So a deadline the rules state in hours, such as the twenty four hours a reversal is given from the moment the originator finds the error, runs from that event on the same clock, and is a different measure from the banking day counts that sit beside it, such as the five banking days the same reversal also has.", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "Appendix B section 1.1, the banking day for receipt of ACH items as a clock window in Eastern time, the processing and transmission cut, and the note that other times apply around weekends and holidays, read 2026-09-20", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.ach-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.hours-what-a-banking-day-is", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.recall-the-two-clocks-on-a-reversal", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Federal Reserve Banks Operating Circular 4, effective 2026-01-05, Appendix B section 1.1, read 2026-09-20, for the clock the operator keeps. [Unverified] No source read for this record says whether an hours deadline the Nacha rules set, the twenty four hours from discovery on a reversal in particular, keeps running through a night, a weekend or a holiday, or pauses; the corpus states only that it is measured from the event rather than from the start of a banking day, and a practitioner should treat it as running.", "confidence": "low" }, "currency": { "effective_since": "2026-01-05", "effective_to": null, "effective_note": "The date is the effective date of the Operating Circular 4 edition read.", "source_edition": "Federal Reserve Banks Operating Circular 4, effective 2026-01-05, read 2026-09-20", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.hours-how-long-the-network-is-open", "id": "rule.hours-how-long-the-network-is-open", "rail": "us-ach", "class": "Rule", "name": "How long the network is open", "statement": "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.", "rests_on": "guidance", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-abcs-of-ach", "section": "read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.settlement-the-settlement-asset-and-its-hours", "note": "The same settlement hours from the same Nacha page. That record says settlement happens in central bank money, which is why the hours are the Federal Reserve's, and adds the FedACH Processing Schedule footnote pointing settlement to the Payment System Risk policy; this one carries the 23 and a quarter hours the network itself is open, which that record does not.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:hours by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:hours by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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": "us-ach:src.nacha-abcs-of-ach", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the ACH Network is open for processing 23 and a quarter hours every business day, settles payments four times a day, and that the Federal Reserve settlement system is closed on weekends, federal holidays, and business days from 6:30 p.m. to 7:30 a.m. Eastern." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.settlement-the-settlement-asset-and-its-hours", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.hours-industry-practice-around-weekends", "id": "rule.hours-industry-practice-around-weekends", "rail": "us-ach", "class": "Rule", "name": "Industry practice around weekends", "statement": "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.", "rests_on": "practice", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-abcs-of-ach", "section": "standard industry practices section, read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:hours by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:hours by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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": "us-ach:src.nacha-abcs-of-ach", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms paydays falling on a weekend or holiday are commonly paid on the prior Friday while bill payments due on those days are collected on the next business day, in each case favoring the consumer, described as standard industry practice." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.hours-one-geographic-exception-to-that-availability", "id": "rule.hours-one-geographic-exception-to-that-availability", "rail": "us-ach", "class": "Rule", "name": "One geographic exception to that availability rule", "statement": "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.", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-minor-topics-funds-availability-exceptions", "section": "quoting Article Three, Subsection 3.3.1.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:hours by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-18", "effective_to": null, "effective_note": "Split out of us-ach:hours by the 2026-09 Orca Core migration; no rule change identified. The line itself dates this from 2026-09-18.", "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": "us-ach:src.nacha-minor-topics-funds-availability-exceptions", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the new Article Three, Subsection 3.3.1.1 language giving an RDFI east of the Atlantic time zone and west of the International Date Line, such as Guam or the Northern Mariana Islands, until the end of the settlement date when a non same day credit arrives after 8 a.m. local time, and until 9 a.m. the following banking day when it arrives after the RDFI finishes processing." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:state.funds-available", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.hours-overnight-windows-for-future-dated-work", "id": "rule.hours-overnight-windows-for-future-dated-work", "rail": "us-ach", "class": "Rule", "name": "Overnight windows for future dated work", "statement": "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.", "rests_on": "guidance", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "us-ach:src.fedach-processing-schedule-2022-09-12", "section": "Future Dated Forward Items table with footnotes 4 and 5, read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.settlement-future-dated-settlement-clock-time", "note": "The same 08:30 Eastern settlement event, from the same FedACH Processing Schedule table. That record is the settlement clock itself and carries the typed time window; this one is the three overnight transmission windows, which that record does not give. The 08:30 sentence here restates that record and adds nothing to it.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:hours by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "2022-09-12", "effective_to": null, "effective_note": "Split out of us-ach:hours by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "us-ach:src.fedach-processing-schedule-2022-09-12", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:hours, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.settlement-future-dated-settlement-clock-time", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.hours-release-not-transmission-is-what-counts", "id": "rule.hours-release-not-transmission-is-what-counts", "rail": "us-ach", "class": "Rule", "name": "Release, not transmission, is what counts", "statement": "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.", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraph 3.4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:hours by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:hours by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:hours, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.same-day-no-deadline-extensions", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.same-day-risk-pended-batches", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.originated", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.sent-to-the-operator", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.hours-return-deadlines-follow-the-same-clock", "id": "rule.hours-return-deadlines-follow-the-same-clock", "rail": "us-ach", "class": "Rule", "name": "Return deadlines follow the same clock", "statement": "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.", "rests_on": "guidance", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "us-ach:src.fedach-processing-schedule-2022-09-12", "section": "Electronic Return Items, FedLine Web Returns and Paper Returns tables with footnote 6, read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:hours by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "2022-09-12", "effective_to": null, "effective_note": "Split out of us-ach:hours by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "us-ach:src.fedach-processing-schedule-2022-09-12", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:hours, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.same-day-returns-regardless-of-forward", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.hours-same-day-credit-funds-availability", "id": "rule.hours-same-day-credit-funds-availability", "rail": "us-ach", "class": "Rule", "name": "When the receiver can use a same day credit", "statement": "A receiving bank has a withdrawal deadline for a Same Day ACH credit that depends on the window it came in: 13:30 local time for the first window, 17:00 local time for the second, and the end of its own processing day for the third. A bank on Atlantic time may measure against Eastern time. A bank east of the Atlantic time zone and west of the International Date Line instead has until 09:00 local time on the banking day after settlement, whichever window was used. Nothing stops a bank from releasing the money sooner.", "rests_on": "rule", "facet": "hours", "parameters": { "time_window": { "times": [ "13:30", "17:00" ], "timezone": "RDFI local time", "on": "banking_day", "text": "13:30 local (first window), 17:00 local (second window), end of processing day (third window)" } }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [], "excludes": [], "text": "credit Same Day Entries" }, "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-providing-faster-funds-availability", "section": "Details and FAQs: same day credit availability and other time zones; technical note naming Article Three, Subsection 3.3.1.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-expanding-same-day-ach", "section": "FAQs: funds availability for credits received in the third window", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.hours-when-the-receiver-can-use-the-money", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.settlement-same-day-settlement-clock-times", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted. Whether the rule effective 2026-09-18, which rewrote Subsection 3.3.1.1 for non same day credits, touched the same day deadlines was checked only against Nacha's page for that rule, which names no change to them [Unverified].", "confidence": "medium" }, "currency": { "effective_since": "2019-09-20", "effective_to": null, "effective_note": "The 13:30 first window deadline and the second window deadline date from 2019-09-20; the third window deadline from 2021-03-19.", "source_edition": "Nacha public rule pages for the rules effective 2019-09-20 and 2021-03-19, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-providing-faster-funds-availability", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms funds from a first window same day credit must be available by 1:30pm RDFI local time, a second window credit by 5:00pm local time, that an RDFI on Atlantic time may measure against Eastern time instead, and that an RDFI east of the Atlantic time zone and west of the International Date Line must instead make same day credit funds available by 9:00am local time on the banking day after settlement; the linked rule on the third processing window confirms that window's credits must be available no later than the end of the RDFI's own processing day, the same end of day standard used for the first two windows." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:state.funds-available", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.hours-same-day-transmission-deadlines", "id": "rule.hours-same-day-transmission-deadlines", "rail": "us-ach", "class": "Rule", "name": "Same day transmission deadlines", "statement": "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.", "rests_on": "guidance", "facet": "hours", "parameters": { "time_window": { "times": [ "10:30", "14:45", "16:45" ], "timezone": "America/New_York", "on": "banking_day", "text": "10:30, 14:45 and 16:45 Eastern" } }, "relations": [ { "type": "sourced_from", "to": "us-ach:src.fedach-processing-schedule-2022-09-12", "section": "Same Day Eligible Forward Items table with footnote 1, read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:hours by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. The typed parameters and the links other than sourced_from were added by the migration from the line's own words and are unchecked.", "confidence": "medium" }, "currency": { "effective_since": "2022-09-12", "effective_to": null, "effective_note": "Split out of us-ach:hours by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "us-ach:src.fedach-processing-schedule-2022-09-12", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:hours, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.same-day-no-deadline-extensions", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.originated", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.hours-what-a-banking-day-is", "id": "rule.hours-what-a-banking-day-is", "rail": "us-ach", "class": "Rule", "name": "What a banking day is", "statement": "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.", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraph 2.1(h), which points to Appendix B for the Reserve Banks' own ACH banking day", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:hours by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:hours by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:hours, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:cal.federal-reserve-banks", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.hours-a-day-off-the-holiday-list-is-still-a-banking-day", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.hours-a-deadline-stated-in-hours-runs-on-the-clock", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.hours-when-the-receiver-can-use-the-money", "id": "rule.hours-when-the-receiver-can-use-the-money", "rail": "us-ach", "class": "Rule", "name": "When the receiver can use the money", "statement": "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.", "rests_on": "rule", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-funds-availability-non-same-day-credits", "section": "quoting Article Three, Subsection 3.3.1.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:hours by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-18", "effective_to": null, "effective_note": "Split out of us-ach:hours by the 2026-09 Orca Core migration; no rule change identified. The line itself dates this from 2026-09-18.", "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": "us-ach:src.nacha-funds-availability-non-same-day-credits", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:hours, whose check against this source confirmed this detail line." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.hours-same-day-credit-funds-availability", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.funds-available", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.iat-addenda-structure", "id": "rule.iat-addenda-structure", "rail": "us-ach", "class": "Rule", "name": "IAT addenda: seven required, twelve at most, and the operator edits", "statement": "An IAT entry detail record carries at most 12 addenda records. Seven are mandatory, one of each addenda type from 10 to 16 in that order, and describe the parties. Up to five more are optional, drawn from foreign correspondent bank addenda (type 18) and remittance addenda (type 17), with no more than two of type 17. The ACH Operator rejects the IAT when the total exceeds 12, when the addenda count in the entry detail record does not match the records attached, when a mandatory addendum is missing or appears twice, when types 10 to 16 are out of sequence, or when there are more than two remittance addenda; types 17 and 18 may appear in any order.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-2021-03-09", "section": "questions 66 to 72", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-iat-faqs", "section": "Format Questions: maximum number of addenda records", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-iat-executive-summary-2008-07-31", "section": "page 3", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.gateway", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.ach-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "2009-09-18", "effective_to": null, "effective_note": "IAT rules in force since 2009-09-18, per Nacha's 2008 executive summary; no later change to this point identified in the sources read.", "source_edition": "Nacha IAT FAQs (web page dated 2021-05-19; PDF revised 2021-03-09), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-iat-faqs-2021-03-09", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the seven mandatory addenda types 10 to 16 in order, up to five optional addenda from types 17 and 18 with no more than two remittance addenda, and that the Operator rejects an IAT exceeding 12 addenda, missing or duplicating a mandatory addendum, or with types 10 to 16 out of sequence." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.iat-contact-registry-from-2027", "id": "rule.iat-contact-registry-from-2027", "rail": "us-ach", "class": "Rule", "name": "IAT contact required in the ACH Contact Registry from 2027-01-01", "statement": "From 2027-01-01 every participating DFI must list an IAT handling contact in Nacha's ACH Contact Registry, next to the ACH operations and fraud or risk contacts already required. The entry is either a named primary and secondary person with title, email and phone, or a department email and working phone; both must be monitored and answered in normal business hours. The existing duties carry over: update within 45 days of a change and verify every year. One team may be listed for several roles if that is how the institution works, and the IAT field can be filled now.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-iat-contact-registry-rule", "section": "Details, Technical (Section 1.14) and Impact; effective 2027-01-01", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-iat-rules-changes-2026-06-12", "section": "ACH Contact Registry", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.gateway", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "2027-01-01", "effective_to": null, "effective_note": "Rule effective 2027-01-01, not yet in force at snapshot 2026-09-19.", "source_edition": "Nacha public rule page Registration of IAT Contacts in the ACH Contact Registry, read 2026-09-19; Nacha blog of 2026-06-12", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-iat-contact-registry-rule", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the 2027-01-01 effective date, the two contact registration formats and the business hours monitoring requirement, and that the existing 45 day update and annual verification duties carry over." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.iat-date-of-birth-field-from-2027", "id": "rule.iat-date-of-birth-field-from-2027", "rail": "us-ach", "class": "Rule", "name": "Date of birth field in the IAT format from 2027-03-19", "statement": "From 2027-03-19 the IAT format gains a field for the date of birth of the people in the payment. Filling it is optional for the sender, in origination and receipt alike, but every institution must be able to receive it. Nacha's reason is that at least a fifth of IAT stop for manual review, and date of birth is the detail that most often lets such a review be closed. [Unverified] Which record and field carries it was not in the source read.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-iat-rules-changes-2026-06-12", "section": "date of birth field, March 19, 2027", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.gateway", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "2027-03-19", "effective_to": null, "effective_note": "Rule effective 2027-03-19, not yet in force at snapshot 2026-09-19; known only from a Nacha news post, not a rule page.", "source_edition": "Nacha blog Prepare Today for Upcoming IAT Rules Changes, 2026-06-12, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-iat-rules-changes-2026-06-12", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the 2027-03-19 effective date, that the field applies to both origination and receipt and is optional to populate but every institution must be ready to receive it, and the roughly one fifth manual review rationale." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.iat-party-information-every-entry", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.iat-definition", "id": "rule.iat-definition", "rail": "us-ach", "class": "Rule", "name": "What makes an entry IAT (definition in force from 2026-09-18)", "statement": "Since 2026-09-18 an entry is IAT when it is the US ACH leg of a payment that crosses the border. The test is whether any leg of the payment touches a financial agency abroad: an account at a foreign office that the funds leave, pass through or reach, or a foreign facility of a financial agency that collects the funds from the payer or pays them out to the payee. A financial agency is any entity the law allows to hold accounts such as deposits, to issue general purpose payment instruments, or to move money for others. The code follows where the institutions handling the money sit, not where the originator or receiver lives [Inference, carried from the 2008 summary of the earlier definition]. In practice the originator and its ODFI decide by knowing the customer's business and asking where the funds are going. An IAT can never be a Same Day Entry.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-definition-of-iat-entries", "section": "Details and Technical: Article Eight, Section 8.55, with Subsection 2.5.8.1 and Sections 8.44 and 8.45; effective 2026-09-18", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-iat-executive-summary-2008-07-31", "section": "Rules Framework item 1, for the earlier definition and its focus on the location of the financial agency", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-web", "section": "General: how to know whether to use IAT", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.gateway", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.limits-eligibility-limits-not-just-dollar-limits", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-18", "effective_to": null, "effective_note": "Replaces the definition in force from 2009-09-18, which asked whether a financial agency office outside US territorial jurisdiction held an account debited or credited in the payment, dealt directly with the payer or payee, or settled any part of it as an intermediary (Nacha executive summary, 2008). Nacha expects some payments to move between domestic and IAT coding under the new wording.", "source_edition": "Nacha public rule page Definition of IAT Entries (effective 2026-09-18), read 2026-09-19; Nacha 2008 executive summary; Nacha IAT FAQ web page", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-definition-of-iat-entries", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the 2026-09-18 effective date, the financial agency test for what makes an entry IAT, the definition of financial agency, and that an IAT entry cannot be a Same Day entry." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.iat-us-jurisdiction-is-domestic", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R85", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.iat-fedglobal-service-scope", "id": "rule.iat-fedglobal-service-scope", "rail": "us-ach", "class": "Rule", "name": "FedGlobal ACH Payments: what it carries, and its end in 2026", "statement": "FedGlobal ACH Payments is the Reserve Banks' own cross-border ACH service: a Reserve Bank acts as Gateway Operator and hands IAT items to a foreign gateway operator under an agreement with it. As read on 2026-09-19 it serves Mexico, with fixed to variable conversion and the foreign currency to foreign currency option called F3X, and Panama, US dollars to US dollars. Outbound it sends credits and, in limited cases, debits, and may pay non-bank participants in a foreign clearing system; inbound it accepts no debits. Items follow the FedACH deposit deadline and must be batched apart from domestic entries, though they may share a file. Operating Circular 4 Appendix G governs it: foreign law can change return times, reversibility, prenotes, dishonor and when the receiver is credited, and the sending bank bears exchange rate risk and fees on returns. On 2025-11-25 the Reserve Banks announced the service will be discontinued by year-end 2026, and it no longer accepts new sign-ups, so a bank starting IAT origination now needs another Gateway [Inference].", "rests_on": "guidance", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-fedglobal-ach-payments", "section": "service page: discontinuation notice, delivery and foreign exchange options, summary of services", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-fedglobal-faqs", "section": "deposit deadline and batching, SEC code, settlement abroad, risks", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "Appendix G, paragraphs 1(a), 1(b), 3 and 5", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-iat-faqs", "section": "FedACH Services: inbound debits, and prenotification and NOC entries", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.gateway", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "The service page, read 2026-09-19, says the service will be discontinued by year-end 2026; no exact end date is given, so effective_to is left empty. [Unverified] The FAQ's deposit deadline of 2:15 a.m. ET was not checked against the current FedACH schedule and is left out of the statement.", "source_edition": "FedGlobal service page and FAQ as read 2026-09-19; Operating Circular 4 effective 2026-01-05", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.frb-fedglobal-ach-payments", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the Mexico and Panama scope with their respective fixed to variable, F3X and fixed to fixed US dollar options, and the 2025-11-25 announcement that the service is discontinued by year-end 2026 and no longer accepts new signups." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.iat-gateway-agreement-with-odfi", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.iat-foreign-exchange-fields", "id": "rule.iat-foreign-exchange-fields", "rail": "us-ach", "class": "Rule", "name": "The foreign exchange fields of the IAT batch header", "statement": "The IAT batch header describes the currency conversion with a Foreign Exchange Indicator, a Foreign Exchange Reference Indicator and a Foreign Exchange Reference, beside the ISO origination and destination currency codes and the destination country. The indicator takes one of three values: FV (fixed to variable), VF (variable to fixed) or FF (fixed to fixed). Who performs the conversion is for the parties to agree; the Nacha rules do not decide it. When the ODFI will not know the rate, as in an FV payment, Nacha's example sets the reference indicator to 3 and leaves the reference blank, the rate being added downstream. An invalid indicator is one of the grounds for a Gateway's R80 return. [Unverified] Whether the reference indicator must be filled on every IAT, including FF entries in US dollars, is not settled by the public sources read: a 2024 practitioner report says an inbound IAT with that field blank passed the ACH Operator.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-2021-03-09", "section": "questions 25, 57, 58 and 59", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-fedglobal-ach-payments", "section": "Foreign Exchange Options", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-fedglobal-faqs", "section": "Nacha SEC codes used for FedGlobal items", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "section": "IAT section, R80", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.moov-ach-issue-1462", "section": "issue body and maintainer replies", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.gateway", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R80", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted.", "confidence": "low" }, "currency": { "effective_since": "2009-09-18", "effective_to": null, "effective_note": "IAT rules in force since 2009-09-18, per Nacha's 2008 executive summary; no later change to this point identified in the sources read.", "source_edition": "Nacha IAT FAQs (web page dated 2021-05-19; PDF revised 2021-03-09), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-iat-faqs-web", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that which party performs the foreign exchange conversion is left to the parties to the transaction and is not decided by the Nacha Operating Rules." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R80", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.iat-gateway-agreement-with-odfi", "id": "rule.iat-gateway-agreement-with-odfi", "rail": "us-ach", "class": "Rule", "name": "Sending IAT needs a Gateway agreement; receiving does not", "statement": "A Gateway must have an agreement with the ODFI, or with the Gateway's own customer, before it transmits that party's IAT entries. An ODFI that offers IAT to its originators therefore contracts with a Gateway that serves the countries wanted, or builds its own relationships abroad: IAT is a format and a code, not a product that reaches every country. An ODFI can buy the service from the Federal Reserve's cross-border service while it lasts (see the FedGlobal Rule) or from a US bank that offers it to correspondent banks; a corporate originator asks its own bank whether it offers IAT and how to enrol. An RDFI needs no agreement with any Gateway to receive IAT.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-2021-03-09", "section": "questions 13, 14, 15 and 27", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-web", "section": "Origination: getting started, and the ODFI agreement; Receipt: RDFI agreement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "section": "IAT section, R81", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.gateway", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.iat-fedglobal-service-scope", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R81", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "2009-09-18", "effective_to": null, "effective_note": "IAT rules in force since 2009-09-18, per Nacha's 2008 executive summary; no later change to this point identified in the sources read.", "source_edition": "Nacha IAT FAQs (web page dated 2021-05-19; PDF revised 2021-03-09), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-iat-faqs-2021-03-09", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that the rules require a Gateway to have an agreement with the ODFI or the Gateway's customer before sending IAT, and that an RDFI needs no agreement with a Gateway to receive IAT." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R81", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.iat-gateway-inbound-debit-limits", "id": "rule.iat-gateway-inbound-debit-limits", "rail": "us-ach", "class": "Rule", "name": "Which inbound IAT each kind of Gateway may bring in", "statement": "What a Gateway may bring into the US depends on what it is. An ACH Operator acting as Gateway limits inbound IAT to credits and reversals, while an ODFI acting as Gateway may bring in debits as well as credits. Outbound, any Gateway may send both. The Federal Reserve, as the FedGlobal gateway, takes no inbound debits because it cannot give the warranties an ODFI gives on them.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-iat-executive-summary-2008-07-31", "section": "Rules Framework item 2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-iat-faqs", "section": "FedACH Services: whether the Federal Reserve as gateway operator allows inbound debit entries", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.gateway", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.ach-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "2009-09-18", "effective_to": null, "effective_note": "IAT rules in force since 2009-09-18, per Nacha's 2008 executive summary; no later change to this point identified in the sources read.", "source_edition": "Nacha IAT FAQs (web page dated 2021-05-19; PDF revised 2021-03-09), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-iat-executive-summary-2008-07-31", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that an ACH Operator acting as Gateway limits inbound IAT to credits and reversals, that an ODFI acting as Gateway may bring in debits as well as credits, and that all Gateways may send both outbound." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.iat-gateway-only-return-codes", "id": "rule.iat-gateway-only-return-codes", "rail": "us-ach", "class": "Rule", "name": "Return reason codes R80 to R85 belong to Gateways", "statement": "Return reason codes R80 to R85 are for Gateways returning international entries; RDFIs use the ordinary codes. R80 to R84 cover an outbound IAT a Gateway cannot carry onward: a bad value in the IAT coding fields (R80), no IAT agreement with the ODFI or the Gateway's customer (R81), an invalid reference to the foreign receiving bank (R82), a settlement failure in the foreign system (R83), or the Gateway's own choice not to process it, because of excess risk or because the foreign system cannot perform the function (R84). R85 is for an entry sent under a domestic code that the RDFI or Gateway identifies as an outbound international payment lacking what the Gateway needs for OFAC compliance. [Unverified] One bank guide gives these codes the 2 banking day window; another lists no time frame.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-web", "section": "Receipt/Exception Processing and Returns: specific return reason codes for IAT", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-2021-03-09", "section": "questions 40 and 87", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "section": "Codes to be used by Gateways for returning IAT entries", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.bmo-ach-return-reason-codes-2025-05", "section": "Codes used by Gateway Operators for the Return of IAT Entries", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.gateway", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R80", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R81", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R82", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R83", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R84", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R85", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "2009-09-18", "effective_to": null, "effective_note": "IAT rules in force since 2009-09-18, per Nacha's 2008 executive summary; no later change to this point identified in the sources read.", "source_edition": "Nacha IAT FAQs (web page dated 2021-05-19; PDF revised 2021-03-09), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-iat-faqs-2021-03-09", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that return reason codes R80 through R85 are for use only by Gateways, restating each code's ground for an outbound IAT return." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R80", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R81", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R82", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R83", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R84", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R85", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.iat-gateway-operator-defined", "id": "rule.iat-gateway-operator-defined", "rail": "us-ach", "class": "Rule", "name": "What a Gateway Operator is and how an institution becomes one", "statement": "A Gateway Operator is an ACH Operator or a participating DFI that is the point where an ACH entry enters or leaves the United States. It is a role defined in the Nacha rules, not a licence: an institution becomes one by actually sending ACH entries across the border. Nacha treats that as a business decision for senior management, since it means setting up a correspondent relationship in the other country and understanding that country's rules, formats, settlement and risks. Gateways carry warranties and liabilities of their own for IAT, set out in Article Five of the Nacha rules. A Reserve Bank acts as Gateway Operator for FedGlobal, and an ODFI acting as Gateway has OFAC obligations beyond flagging suspect items.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-web", "section": "General: what a Gateway Operator is, and how to become one; OFAC Compliance: additional warranties", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-2021-03-09", "section": "questions 8, 9 and 94", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-iat-executive-summary-2008-07-31", "section": "Rules Framework item 2", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-iat-faqs", "section": "OFAC Questions: the role of a gateway operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.gateway", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "2009-09-18", "effective_to": null, "effective_note": "IAT rules in force since 2009-09-18, per Nacha's 2008 executive summary; no later change to this point identified in the sources read.", "source_edition": "Nacha IAT FAQs (web page dated 2021-05-19; PDF revised 2021-03-09), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-iat-faqs-web", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the Gateway Operator definition as an ACH Operator or participating DFI at the entry or exit point, and that becoming one is a senior management business decision weighing the correspondent relationship, foreign rules, formatting, settlement and risk." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.iat-no-dishonored-returns", "id": "rule.iat-no-dishonored-returns", "rail": "us-ach", "class": "Rule", "name": "No dishonored or contested dishonored returns on IAT", "statement": "No return reason code is barred from an IAT, but the dishonored return and contested dishonored return process does not run for IAT: an ODFI cannot dishonor a returned IAT through the network, and an RDFI cannot contest one there. Any such dispute is handled outside the ACH Network. Operating Circular 4 likewise warns that returned FedGlobal items may not be dishonorable under foreign rules.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-web", "section": "Receipt/Exception Processing and Returns: codes not usable with IAT, and dishonoring a returned IAT", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-2021-03-09", "section": "questions 41, 47, 50 and 88", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "section": "dishonored and contested dishonored return codes, each marked usable for all entries except IAT", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "Appendix G, paragraph 1(a)", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.dishonor-codes-exclude-iat", "note": "The same exclusion stated from the other side, and neither record contains the other. That record names the excluded codes, R61, R62, R67 to R70 and R71 to R77, and is the one the thirteen dishonor and contest reason codes link to; this one rests on Nacha's IAT FAQs for what happens instead.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "2009-09-18", "effective_to": null, "effective_note": "IAT rules in force since 2009-09-18, per Nacha's 2008 executive summary; no later change to this point identified in the sources read.", "source_edition": "Nacha IAT FAQs (web page dated 2021-05-19; PDF revised 2021-03-09), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-iat-faqs-2021-03-09", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that dishonored and contested dishonored returns are not supported for IAT and that any such dispute is handled outside the ACH Network." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.dishonor-codes-exclude-iat", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.dishonor-contested", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.return-dishonored", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.iat-notifications-of-change", "id": "rule.iat-notifications-of-change", "rail": "us-ach", "class": "Rule", "name": "Notifications of Change on IAT", "statement": "The Nacha rules allow Notifications of Change on IAT, but one will only come back if the Gateway and the foreign side support the process, so check with them first. An IAT NOC is marked with the code IATCOR and carries none of the IAT addenda, types 10 to 18. Three change codes that correct several fields at once, C03, C06 and C07, cannot be used for outbound IAT because the correction fields are too short. FedGlobal applies its own specifications to NOCs.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-web", "section": "Receipt/Exception Processing and Returns: IAT NOCs and the IATCOR code", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-2021-03-09", "section": "questions 48, 49, 85, 89, 90 and 91", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-iat-faqs", "section": "FedACH Services: prenotification and notification of change entries", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.gateway", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "2009-09-18", "effective_to": null, "effective_note": "IAT rules in force since 2009-09-18, per Nacha's 2008 executive summary; no later change to this point identified in the sources read.", "source_edition": "Nacha IAT FAQs (web page dated 2021-05-19; PDF revised 2021-03-09), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-iat-faqs-2021-03-09", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that NOCs on IAT are supported by the rules but depend on the correspondent or gateway side, that IATCOR is mandatory, and that C03, C06 and C07 cannot be used for outbound IAT because of field length limits." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.iat-ofac-hold-before-posting", "id": "rule.iat-ofac-hold-before-posting", "rail": "us-ach", "class": "Rule", "name": "Holding a suspect IAT, funds availability, and the sanctions return", "statement": "An RDFI should screen IAT before posting, and a suspect item must stay unposted until it is reviewed and cleared; Nacha reports that OFAC wrote in 2012 that screening after crediting the beneficiary raises a bank's risk substantially. Apart from that, an RDFI may not delay funds from an IAT credit just because the entry needs OFAC review; the ordinary availability deadline applies. An IAT flagged as a possible match cannot simply be returned: it must be handled as OFAC requires, and a confirmed match on an inbound debit is reported to OFAC, which decides case by case. If the review outlasts the return window, Article One, Subsection 1.2.1 (Effect of Illegality) of the Nacha rules gives the RDFI time to finish it, and a debit that clears review may then be returned for ordinary reasons such as a debit block. Until 2028-03-17 a return driven by sanctions uses R16; from that date it uses R90, due 2 banking days after the RDFI's determination, and R16 is left for frozen accounts.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-2021-03-09", "section": "questions 16, 33, 35, 39, 56, 103 and 107", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-web", "section": "Receipt/Exception Processing and Returns: screening before posting, positive indicators, and research beyond the return time frame", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-sanctions-compliance-return-code", "section": "effective date and window of R90", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-iat-rules-changes-2026-06-12", "section": "R90 and the narrowing of R16", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R90", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R16", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.return-window-sanctions-determination", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.decision-points-whether-an-entry-breaches-sanctions-obligations", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "2009-09-18", "effective_to": null, "effective_note": "IAT rules in force since 2009-09-18, per Nacha's 2008 executive summary; no later change to this point identified in the sources read. The R16 to R90 split takes effect 2028-03-17.", "source_edition": "Nacha IAT FAQs (web page dated 2021-05-19; PDF revised 2021-03-09), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-iat-faqs-2021-03-09", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms screening before posting with a suspect item held until cleared, the 2012 OFAC letter on the added risk of screening after crediting, that a positive match cannot simply be returned, and that Article One Subsection 1.2.1 gives the RDFI time to investigate beyond the return window." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:state.posted", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.iat-ofac-screening-duties", "id": "rule.iat-ofac-screening-duties", "rail": "us-ach", "class": "Rule", "name": "Who must screen an IAT for sanctions", "statement": "Sanctions screening of an IAT falls on every party in the chain and cannot be handed off. Nacha names the Gateway, the Originator, the ODFI and the RDFI as each responsible for OFAC compliance on IAT; a bank may outsource the screening work but never its OFAC liability. The ACH Operators do no OFAC review in that capacity: the Federal Reserve screens only the inbound IAT it handles as FedGlobal gateway, flags them and never holds, pends or rejects one, and EPN sells screening only as an optional service. OFAC's 2004 letter to Nacha put the inbound duty on US RDFIs, which must see that every part of an inbound cross-border entry complies and act on it as needed, and the outbound duty on ODFIs and their originators, covering both the parties and the purpose of each payment. An ODFI acting as Gateway carries OFAC obligations beyond flagging. For purely domestic entries OFAC's 1997 letter let the network rely mainly on RDFIs and did not expect ODFIs to unbatch customer files.", "rests_on": "guidance", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-web", "section": "OFAC Compliance and Rules Enforcement: contracting away liability, the operators' role, which parties must screen, and operator screening services", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-2021-03-09", "section": "questions 96, 100, 101 and 108", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-iat-faqs", "section": "OFAC Questions", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.ofac-letters-to-nacha-1997-2004", "section": "letter of 2004-11-09, page 2; letter of 1997-03-20, pages 1 and 2", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-iat-executive-summary-2008-07-31", "section": "page 3", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.gateway", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.ach-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.decision-points-whether-an-entry-breaches-sanctions-obligations", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.iat-ofac-screening-indicators", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "OFAC's position dates from its letters of 1997 and 2004; the Nacha IAT allocation from 2009-09-18. No later change identified in the sources read.", "source_edition": "Nacha IAT FAQs and Federal Reserve IAT FAQ as read 2026-09-19; OFAC letters to Nacha of 1997-03-20 and 2004-11-09", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-iat-faqs-web", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that the Gateway Operator, Originator, ODFI and RDFI must each screen IAT for OFAC compliance and cannot contract away the liability, that ACH Operators do no OFAC review in that capacity, and that EPN offers screening only as a value added service to its own customers." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.iat-ofac-screening-indicators", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.iat-ofac-screening-indicators", "id": "rule.iat-ofac-screening-indicators", "rail": "us-ach", "class": "Rule", "name": "Where the OFAC screening indicators sit in an IAT", "statement": "The IAT entry detail record has two OFAC screening indicator fields: field 10, the Gateway Operator indicator, and field 11, the secondary indicator, which Nacha assigns to a third-party service provider and the 2008 summary to a correspondent bank. When used, each reads 1 for a possible sanctions match and 0 for none. Nacha calls both optional for inbound IAT, though the Federal Reserve fills field 10 on the inbound items it handles as FedGlobal gateway [Unverified: the Federal Reserve FAQ says gateway operators are required to screen incoming IAT, which reads stricter than Nacha's optional]. An RDFI must not overwrite an indicator already filled, and a 0 does not relieve it of its own screening.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-iat-faqs", "section": "Format Questions and OFAC Questions: where the OFAC screening indicator is located, and the role of a gateway operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-2021-03-09", "section": "questions 65, 99 and 106", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-iat-executive-summary-2008-07-31", "section": "page 3", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.gateway", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.iat-ofac-screening-duties", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "2009-09-18", "effective_to": null, "effective_note": "IAT rules in force since 2009-09-18, per Nacha's 2008 executive summary; no later change to this point identified in the sources read.", "source_edition": "Nacha IAT FAQs (web page dated 2021-05-19; PDF revised 2021-03-09), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-iat-faqs-2021-03-09", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms field 10 as the Gateway Operator indicator and field 11 as the secondary indicator populated by a third party service provider, the 0 and 1 values, and that an RDFI must not change or write over an indicator already populated." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.iat-ofac-screening-duties", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.iat-one-code-consumer-and-business", "id": "rule.iat-one-code-consumer-and-business", "rail": "us-ach", "class": "Rule", "name": "One IAT code for consumer and business entries", "statement": "IAT is a single SEC code used for every international entry, whether the account is a consumer's or a business's; there is no separate consumer or corporate variant. The account type still decides which protections apply: an IAT to or from a US consumer account gets the same US consumer protections, Regulation E included, as a PPD would, while parties abroad stay under their own country's law.", "rests_on": "rule", "facet": "consumer-law", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-web", "section": "General: consumer protections, and consumer versus corporate IAT", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-2021-03-09", "section": "questions 4, 5, 6 and 60", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-iat-faqs", "section": "General Questions: major changes with the IAT code", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.consumer-law-what-is-covered", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "2009-09-18", "effective_to": null, "effective_note": "IAT rules in force since 2009-09-18, per Nacha's 2008 executive summary; no later change to this point identified in the sources read.", "source_edition": "Nacha IAT FAQs (web page dated 2021-05-19; PDF revised 2021-03-09), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-iat-faqs-web", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that IAT is the single SEC code for both consumer and corporate international entries and that US consumer protections under Regulation E apply to it as they do to PPD, while parties outside the US are bound by their own country's law." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.iat-party-information-every-entry", "id": "rule.iat-party-information-every-entry", "rail": "us-ach", "class": "Rule", "name": "Party information every IAT must carry", "statement": "Every IAT must carry the party details that the Bank Secrecy Act Travel Rule requires of funds transfers, whatever the amount: Nacha applies it to all IAT, not only above the Travel Rule's $3,000 threshold. The mandatory addenda hold the reason for payment (a three character code in the transaction type code field of the first addendum); the receiving bank, the originating bank and any foreign correspondent bank, each with name, identifier and branch country; and both end parties, originator and receiver, with name and physical address, which OFAC asked for. For an inbound IAT the fourth addendum describes the foreign originating bank, while the US ODFI or Gateway is named in the batch header. Countries are written as two letter ISO 3166-1 codes. A date of birth field is added from 2027-03-19 (see its own Rule).", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-web", "section": "General: Travel Rule information", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-2021-03-09", "section": "questions 12, 20, 73, 74, 77 and 79", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-iat-faqs", "section": "Format Questions: mandatory addenda data elements, and the transaction type code field", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-iat-executive-summary-2008-07-31", "section": "pages 2 and 3", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.ofac-letters-to-nacha-1997-2004", "section": "letter of 2004-11-09, page 1", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.gateway", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.iat-date-of-birth-field-from-2027", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "2009-09-18", "effective_to": null, "effective_note": "IAT rules in force since 2009-09-18, per Nacha's 2008 executive summary; no later change to this point identified in the sources read.", "source_edition": "Nacha IAT FAQs (web page dated 2021-05-19; PDF revised 2021-03-09), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-iat-faqs-2021-03-09", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that the rules require Travel Rule party information on every IAT regardless of the BSA's 3,000 dollar threshold, and that OFAC's request is the reason a physical address is required on IAT unlike a wire transfer." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.iat-prenotes", "id": "rule.iat-prenotes", "rail": "us-ach", "class": "Rule", "name": "Prenotes on IAT: allowed inbound, rarely answered outbound", "statement": "A prenote may precede a live IAT. An inbound IAT prenote must carry the seven mandatory IAT addenda and be screened for OFAC like a live entry. The rules do not apply prenotes to outbound IAT, since most foreign payment systems have no such message; an outbound prenote still passes the ACH Operator, but it will seldom cross the border, and the foreign bank will usually not reply. A zero dollar IAT may go to a demand or savings account but not to a general ledger or loan account. FedGlobal applies its own edits to prenotes.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-web", "section": "Origination: IAT pre-notes, and transaction codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-2021-03-09", "section": "questions 21, 22, 63 and 64", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-iat-faqs", "section": "FedACH Services: prenotification and notification of change entries", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.gateway", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "2009-09-18", "effective_to": null, "effective_note": "IAT rules in force since 2009-09-18, per Nacha's 2008 executive summary; no later change to this point identified in the sources read.", "source_edition": "Nacha IAT FAQs (web page dated 2021-05-19; PDF revised 2021-03-09), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-iat-faqs-2021-03-09", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that an inbound IAT prenote must carry the seven mandatory addenda and be OFAC screened, that most countries do not support prenotes so an outbound one seldom draws a reply, and that a zero dollar IAT may go to a demand or savings account but not a general ledger or loan account." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R84", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.iat-rdfi-must-accept", "id": "rule.iat-rdfi-must-accept", "rail": "us-ach", "class": "Rule", "name": "An RDFI must accept IAT and may not refuse it for being IAT", "statement": "Any US RDFI may receive an IAT, credit or debit, and must take it: IAT is not an SEC code an RDFI can opt out of, and it may not reject or return an entry only because it is IAT and the RDFI would rather not handle IAT. It can still return an IAT for any reason the rules allow, for example when its customer says an entry was unauthorized and the entry is not a sanctions match. Nothing in the rules stops an RDFI from charging to receive and process IAT. IAT is the only SEC code whose entry detail and addenda records the RDFI must review.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-web", "section": "Receipt/Exception Processing and Returns: first eight questions", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-2021-03-09", "section": "questions 26, 28, 29, 31, 37 and 38", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-iat-faqs", "section": "General Questions: who the IAT code impacts", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "2009-09-18", "effective_to": null, "effective_note": "IAT rules in force since 2009-09-18, per Nacha's 2008 executive summary; no later change to this point identified in the sources read.", "source_edition": "Nacha IAT FAQs (web page dated 2021-05-19; PDF revised 2021-03-09), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-iat-faqs-2021-03-09", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that any US RDFI may receive an IAT, that IAT is not an optional acceptance SEC code, that an RDFI cannot return an IAT solely because it is IAT while ordinary return reasons still apply, and that IAT is the only SEC code requiring entry detail and addenda review." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.iat-replaced-cbr-and-pbr", "id": "rule.iat-replaced-cbr-and-pbr", "rail": "us-ach", "class": "Rule", "name": "Why IAT replaced the older cross-border codes", "statement": "IAT took effect on 2009-09-18 in place of the older cross-border codes CBR and PBR [Unverified: that CBR served business and PBR consumer entries is general knowledge; the sources read name both codes but not their split]. OFAC had asked Nacha for it. The older formats did not say enough about the parties for a receiving bank to screen them, and many international payments reached US banks through correspondent relationships looking like domestic entries, so no one could tell they were international. IAT fixed both: it carries the party details the Bank Secrecy Act Travel Rule requires, adds OFAC screening indicators, and makes a cross-border entry recognisable by its code.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-iat-executive-summary-2008-07-31", "section": "pages 1 to 3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-iat-faqs", "section": "General Questions: what IAT is, and why it was necessary", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.ofac-letters-to-nacha-1997-2004", "section": "letter of 2004-11-09, page 1", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-2021-03-09", "section": "question 1", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.gateway", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "2009-09-18", "effective_to": null, "effective_note": "IAT rules in force since 2009-09-18, per Nacha's 2008 executive summary; no later change to this point identified in the sources read.", "source_edition": "Nacha IAT FAQs (web page dated 2021-05-19; PDF revised 2021-03-09), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-iat-executive-summary-2008-07-31", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that CBR and PBR lacked information for an RDFI to identify IAT parties, that the change responded to OFAC's request, and that the new format carries the Travel Rule data and OFAC screening indicators." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.iat-return-addenda", "id": "rule.iat-return-addenda", "rail": "us-ach", "class": "Rule", "name": "Which addenda travel with a returned IAT", "statement": "A returned IAT carries the seven mandatory IAT addenda of the original entry (types 10 to 16) plus the return addendum; the optional remittance and foreign correspondent addenda (types 17 and 18) are not sent with the return. The addenda count field is copied unchanged from the original, and the ACH Operators do not check it against the records attached to a return or NOC. The ACH Operator rejects an IAT return that lacks a mandatory addendum or repeats one.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-2021-03-09", "section": "questions 70, 71, 84 and 86", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-iat-executive-summary-2008-07-31", "section": "page 3", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.gateway", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "2009-09-18", "effective_to": null, "effective_note": "IAT rules in force since 2009-09-18, per Nacha's 2008 executive summary; no later change to this point identified in the sources read.", "source_edition": "Nacha IAT FAQs (web page dated 2021-05-19; PDF revised 2021-03-09), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-iat-faqs-2021-03-09", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that the seven mandatory IAT addenda travel with a return while types 17 and 18 do not, that the addenda count field is copied unchanged and not checked by the Operator, and that this matches CTX return handling." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.format-return-entry-construction", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.iat-return-amount-may-differ", "id": "rule.iat-return-amount-may-differ", "rail": "us-ach", "class": "Rule", "name": "A returned IAT can come back for a different amount", "statement": "When an outbound IAT was converted into a foreign currency and is then returned, it is converted back to US dollars, possibly at a different rate, so the amount that comes back can differ from the amount sent. Through FedGlobal the sending bank bears the exchange rate movement and any fees on a returned item, and the foreign exchange spread is applied to both the original and the return.", "rests_on": "rule", "facet": "return", "parameters": { "liability_holder": { "role": "us-ach:role.odfi", "condition": "a returned outbound cross-border item sent through FedGlobal, as to exchange rate movement and fees", "text": "The sending bank (the ODFI) bears exchange rate movement and fees on a returned FedGlobal item." } }, "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-web", "section": "Receipt/Exception Processing and Returns: conversion amount on a return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-2021-03-09", "section": "question 43", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "Appendix G, paragraphs 5(a) and 5(c)", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-fedglobal-faqs", "section": "risks associated with FedGlobal transactions", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "IAT rules in force since 2009-09-18, per Nacha's 2008 executive summary; no later change to this point identified in the sources read.", "source_edition": "Nacha IAT FAQs (web page dated 2021-05-19; PDF revised 2021-03-09), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-iat-faqs-2021-03-09", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that a returned outbound IAT converted back to US dollars can come back at a different amount because of a potentially different exchange rate." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R83", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.iat-return-timeframes", "id": "rule.iat-return-timeframes", "rail": "us-ach", "class": "Rule", "name": "Return time frames for inbound and outbound IAT", "statement": "For IAT coming into the US, the ordinary Nacha return time frames apply unchanged. For an unauthorized IAT, which may be to a consumer or a business account, Nacha's 2021 PDF says the RDFI may use the consumer time frame, while its web page says IAT uses the same time frames as other entries [Unverified: which reading Nacha holds today]. For IAT going out of the US, the receiving country's rules set the return time, which varies by country and can be longer than domestic; the ODFI learns it from its Gateway. A copy of an inbound IAT's authorization may be requested, but what counts as authorization and how quickly it must be produced depend on the originating country, and the domestic deadline for producing it does not apply.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-web", "section": "Receipt/Exception Processing and Returns: return timeframes, unauthorized entries, and authorization copies; Origination: foreign return timeframes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-2021-03-09", "section": "questions 23, 42, 44, 45 and 46", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "Appendix G, paragraph 1(a)", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-fedglobal-faqs", "section": "risks associated with FedGlobal transactions", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.return-window-2-banking-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.return-window-60-calendar-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "2009-09-18", "effective_to": null, "effective_note": "IAT rules in force since 2009-09-18, per Nacha's 2008 executive summary; no later change to this point identified in the sources read.", "source_edition": "Nacha IAT FAQs (web page dated 2021-05-19; PDF revised 2021-03-09), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-iat-faqs-2021-03-09", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms unchanged domestic return timeframes for inbound IAT, that outbound IAT return timing is set by the receiving country, that a domestic authorization production deadline does not apply to an inbound IAT authorization request, and this document's own statement that the RDFI may use the consumer timeframe for an unauthorized IAT, which the same publisher's web FAQ states differently." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.iat-reversal-best-effort", "id": "rule.iat-reversal-best-effort", "rail": "us-ach", "class": "Rule", "name": "Reversing an IAT is best effort only", "statement": "The Nacha rules allow an IAT to be reversed, but for an outbound entry the reversal is only a best effort attempt: the receiving country may not support reversals at all. Operating Circular 4 lists non-reversibility among the ways foreign rules can change the outcome of a FedGlobal item, and FedGlobal applies its own specifications to recalls and reversals.", "rests_on": "rule", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-web", "section": "Origination: whether an IAT can be reversed", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-2021-03-09", "section": "questions 24 and 62", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "Appendix G, paragraph 1(a)", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-iat-faqs", "section": "FedACH Services: prenotification and notification of change entries", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.finality-reversals-exist-and-they-are-new-entries", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "2009-09-18", "effective_to": null, "effective_note": "IAT rules in force since 2009-09-18, per Nacha's 2008 executive summary; no later change to this point identified in the sources read.", "source_edition": "Nacha IAT FAQs (web page dated 2021-05-19; PDF revised 2021-03-09), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-iat-faqs-2021-03-09", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that an IAT reversal is allowed but handled on a best effort basis because the receiving country may not support reversals." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R84", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.iat-separate-file-option", "id": "rule.iat-separate-file-option", "rail": "us-ach", "class": "Rule", "name": "Receiving IAT in a separate file (FedACH option)", "statement": "FedACH lets an RDFI or its receiving point choose to get its IAT items in a file of their own, apart from domestic items, by signing up through the FedACH Participation Agreement. The file holds all forward IAT items for the institution, whichever Gateway they came through, in every distribution window, but not IAT returns, which need a separate request to the relationship manager. The FedPayments Reporter Service offers a daily IAT report instead or as well. This is an operator service, not a Nacha rule.", "rests_on": "guidance", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-iat-faqs", "section": "FedACH Services: tools to monitor IAT items", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.ach-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Operator service described on an undated Federal Reserve FAQ read 2026-09-19; its current fee and availability were not checked.", "source_edition": "Federal Reserve IAT FAQ, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.frb-iat-faqs", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the separate IAT file option through the FedACH Participation Agreement, that it carries all forward IAT items but not returns, that it follows each FedACH distribution window, and the FedPayments Reporter daily IAT report alternative." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.iat-us-jurisdiction-is-domestic", "id": "rule.iat-us-jurisdiction-is-domestic", "rail": "us-ach", "class": "Rule", "name": "Military bases and embassies abroad count as domestic", "statement": "Payments to or from US military bases, embassies and similar posts abroad are treated as inside US jurisdiction, so they go as domestic entries and do not need the IAT code. [Unverified] Nacha's answer was written under the earlier IAT definition and has not been restated since the 2026-09-18 definition; whether it still holds when a financial agency office abroad handles the funds is not stated.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-web", "section": "General: military bases and embassies", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-2021-03-09", "section": "question 3", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.iat-definition", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "2009-09-18", "effective_to": null, "effective_note": "IAT rules in force since 2009-09-18, per Nacha's 2008 executive summary; no later change to this point identified in the sources read.", "source_edition": "Nacha IAT FAQs (web page dated 2021-05-19; PDF revised 2021-03-09), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-iat-faqs-web", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that entries from US military bases and embassies abroad are treated as domestic and do not require IAT; the page is dated 2021-05-19, before the 2026-09-18 IAT definition." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.liability-article-4a-credits-are-a-separate-regime", "id": "rule.liability-article-4a-credits-are-a-separate-regime", "rail": "us-ach", "class": "Rule", "name": "Article 4A credits are a separate regime", "statement": "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).", "rests_on": "law", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraph 22.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:liability by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:liability by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:liability, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.liability-banks-indemnify-the-operator-not-the-other-way", "id": "rule.liability-banks-indemnify-the-operator-not-the-other-way", "rail": "us-ach", "class": "Rule", "name": "Banks indemnify the operator, not the other way round", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraphs 5.1 and 12.1(d)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:liability by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:liability by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:liability, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.liability-fraud-duties-are-monitoring-duties-not-a-loss", "id": "rule.liability-fraud-duties-are-monitoring-duties-not-a-loss", "rail": "us-ach", "class": "Rule", "name": "Fraud duties are monitoring duties, not a loss rule", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-fraud-monitoring-phase-1", "section": "read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-fraud-monitoring-phase-2", "section": "read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:liability by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "2026-03-20", "effective_to": null, "effective_note": "Split out of us-ach:liability by the 2026-09 Orca Core migration; no rule change identified. The line itself dates this from 2026-03-20.", "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, "corroboration": [ { "source": "us-ach:src.nacha-fraud-monitoring-phase-1", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms Phase 1 takes effect March 20, 2026 for ODFIs and larger originating and receiving participants, with the rest following June 19, 2026, and defines False Pretenses as inducing payment by misrepresenting identity, authority to act for another, or ownership of the credited account." }, { "source": "us-ach:src.nacha-fraud-monitoring-phase-2", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms Phase 2 takes effect June 19, 2026 and that Nacha expressly states the new monitoring requirements do not change the allocation of liability among participants under otherwise applicable law." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.liability-how-damages-against-the-operator-are-measured", "id": "rule.liability-how-damages-against-the-operator-are-measured", "rail": "us-ach", "class": "Rule", "name": "How damages against the operator are measured", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraph 21.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:liability by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:liability by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:liability, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.liability-outsourced-screening-stays-the-bank-s-problem", "id": "rule.liability-outsourced-screening-stays-the-bank-s-problem", "rail": "us-ach", "class": "Rule", "name": "Outsourced screening stays the bank's problem", "statement": "A bank that hands its sanctions checking to an agent or a service provider still answers for whether the checking was done properly, exactly as it would for anything else it contracted out, so it is expected to put controls and a review process around that relationship rather than treat the contract as the end of the matter. The same thinking reaches its ACH traffic generally: a bank with third-party service provider relationships is expected to work out what exposure those bring and write procedures for it.", "rests_on": "law", "facet": "liability", "parameters": { "liability_holder": { "role": "us-ach:role.rdfi", "condition": "sanctions screening performed by an agent or service provider on the bank's behalf", "text": "The account holding bank answers for the screening, whoever performs it; the same holds for an originating bank that outsources its own checks." } }, "relations": [ { "type": "sourced_from", "to": "us-ach:src.ffiec-bsa-aml-ofac-overview", "section": "the passage on a bank using a third party such as an agent or service provider to perform OFAC checks, and the Screening ACH transactions passage on third-party service provider relationships, read 2026-09-20", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:role.third-party-service-provider", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The FFIEC BSA/AML Examination Manual OFAC chapter as posted by OFAC, read 2026-09-20. The typed liability_holder names the receiving bank because that is the case the chapter spells out; the statement covers an originating bank that outsources too, which the chapter reaches through its general wording about a third party performing OFAC checks. [Unverified] The chapter says nothing about how liability is apportioned between a bank and its vendor by contract, and the corpus makes no claim about that.", "confidence": "medium" }, "currency": { "effective_since": "2007-08-24", "effective_to": null, "effective_note": "The date is the one footed on the chapter's pages; the principle it states is older than the chapter.", "source_edition": "FFIEC BSA/AML Examination Manual, OFAC overview, pages footed 8/24/2007, as read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.ffiec-bsa-aml-ofac-overview", "checked_on": "2026-09-20", "checked_by": "validator-us-ach-core-2026-09-20", "notes": "Confirms that when a bank uses a third party such as an agent or service provider to perform OFAC checks, the bank remains ultimately responsible for that third party's compliance and should establish controls and review procedures for the relationship, and that the same expectation reaches a bank's third-party service provider relationships for its ACH traffic generally." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.liability-settlement-risk-sits-with-the-reserve-banks", "id": "rule.liability-settlement-risk-sits-with-the-reserve-banks", "rail": "us-ach", "class": "Rule", "name": "Settlement risk sits with the Reserve Bank's discretion", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraphs 10.3 and 10.4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:liability by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:liability by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms paragraph 10.4, a Reserve Bank's discretion to refuse to settle where it doubts sufficient funds will cover a debit or credit item, and paragraph 10.3, the security interest the sending or receiving bank grants a Reserve Bank in its property and the Reserve Bank's right to set off without demand or notice." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:state.settlement-unwound", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.liability-the-60-day-line-on-a-statement", "id": "rule.liability-the-60-day-line-on-a-statement", "rail": "us-ach", "class": "Rule", "name": "The 60 day line on a statement", "statement": "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.", "rests_on": "law", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "us-ach:src.reg-e-12-cfr-1005", "section": "1005.6(b)(3) and (b)(4), read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:liability by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:liability by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.reg-e-12-cfr-1005", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms 1005.6(b)(3), the sixty day statement reporting deadline and the resulting liability for later transfers the institution can show would not have occurred with timely notice, and 1005.6(b)(4), the extension of the deadline for extenuating circumstances." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.liability-the-consumers-exposure-is-capped", "id": "rule.liability-the-consumers-exposure-is-capped", "rail": "us-ach", "class": "Rule", "name": "The consumer's exposure is capped", "statement": "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.", "rests_on": "law", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "us-ach:src.reg-e-12-cfr-1005", "section": "1005.6(a) and 1005.6(b)(1) and (2), read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:liability by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:liability by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing. Merged 2026-09-20: us-ach:rule.consumer-law-the-loss-cap stated the same Regulation E caps, the same notice period and the same disclosure condition from the same source, and was deleted; the us-ach consumer-law fact that listed it now lists this record. This record was kept because its citation is the fuller one, 1005.6(a) and 1005.6(b)(1) and (2) against 1005.6(a) and 1005.6(b), and because its corroboration note records a check of each of those paragraphs.", "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, "corroboration": [ { "source": "us-ach:src.reg-e-12-cfr-1005", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms 1005.6(b)(1), the fifty dollar cap when the consumer notifies within two business days of learning of loss or theft, 1005.6(b)(2), the five hundred dollar cap when notice is not timely, and 1005.6(a), that both caps depend on the institution having given the required disclosures." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.liability-the-operators-liability-and-what-it-is-not", "id": "rule.liability-the-operators-liability-and-what-it-is-not", "rail": "us-ach", "class": "Rule", "name": "The operator's liability, and what it is not", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraph 21.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:liability by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:liability by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:liability, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.liability-the-warranty-that-carries-loss-back-to-the", "id": "rule.liability-the-warranty-that-carries-loss-back-to-the", "rail": "us-ach", "class": "Rule", "name": "The warranty that carries loss back to the originating side", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-limitation-on-warranty-claims", "section": "read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:liability by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "2021-06-30", "effective_to": null, "effective_note": "Split out of us-ach:liability by the 2026-09 Orca Core migration; no rule change identified. The line itself dates this from 2021-06-30. Merged 2026-09-20: us-ach:rule.refund-after-the-return-window-a-warranty-claim stated the same authorisation warranty claim and the same three limits, one year, 95 days and two years, from the same source, and was deleted; the us-ach refund fact that listed it now lists this record. The two were equally sourced, one corroboration each against Nacha's limitation on warranty claims, and this record was kept because the us-ach competency bank already names it and because it states the warranty itself rather than only when the claim may be brought.", "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, "corroboration": [ { "source": "us-ach:src.nacha-limitation-on-warranty-claims", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:liability, whose check against this source confirmed this detail line." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.liability-two-deadlines-that-quietly-destroy-claims", "id": "rule.liability-two-deadlines-that-quietly-destroy-claims", "rail": "us-ach", "class": "Rule", "name": "Two deadlines that quietly destroy claims", "statement": "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.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraphs 16.2, 21.1(d) and 23.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:liability by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:liability by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:liability, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.limits-ach-debits-to-a-savings-account", "id": "rule.limits-ach-debits-to-a-savings-account", "rail": "us-ach", "class": "Rule", "name": "ACH debits to a savings account", "statement": "A savings account can be debited by ACH. The federal count that used to cap convenient transfers out of a savings deposit at six a month was taken out of the definition of a savings deposit on 2020-04-24, and the Board has said it does not plan to put it back, but each depository institution chooses whether to stop enforcing a count of its own. So a debit to a savings account fails on a restriction the institution still keeps, not on a federal limit, and that failure is R20.", "rests_on": "law", "facet": "limits", "applies_to": { "direction": "debit", "account_type": "any", "transaction_types": [], "excludes": [], "text": "debits to a savings or other non-checking deposit account" }, "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-savings-deposits-faq", "section": "the questions on what the April 2020 interim final rule deleted, on whether an institution must suspend the six transfer limit, and on whether the change is permanent, read 2026-09-20", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R20", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The Federal Reserve Board's Savings Deposits FAQ on the Regulation D interim final rule of 2020-04-24. [Inference] That an entry a retained institutional restriction turns away comes back as R20 rests on the corpus's own R20 record, whose meaning is an account that does not permit the transaction sent; the Board's page does not mention ACH return codes.", "confidence": "medium" }, "currency": { "effective_since": "2020-04-24", "effective_to": null, "effective_note": "The Board announced the interim final rule deleting the six per month limit on 2020-04-24 and describes the change as permanent.", "source_edition": "Federal Reserve Board, Savings Deposits Frequently Asked Questions, read 2026-09-20", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.limits-eligibility-limits-not-just-dollar-limits", "id": "rule.limits-eligibility-limits-not-just-dollar-limits", "rail": "us-ach", "class": "Rule", "name": "Eligibility limits, not just dollar limits", "statement": "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.", "rests_on": "rule", "facet": "limits", "parameters": { "eligibility": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [ "us-ach:txn.iat", "us-ach:txn.enr" ], "text": "every SEC code except IAT and ENR" } }, "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraph 3.3(b)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-same-day-ach-limit-10-million", "section": "which states IAT stays ineligible", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:limits by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. The typed parameters and the links other than sourced_from were added by the migration from the line's own words and are unchecked.", "confidence": "medium" }, "currency": { "effective_since": "2022-03-18", "effective_to": null, "effective_note": "Split out of us-ach:limits by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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, "corroboration": [ { "source": "us-ach:src.nacha-same-day-ach-limit-10-million", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:limits, whose check against this source confirmed this detail line." }, { "source": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:limits, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.iat-definition", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.same-day-ineligible-entry-settles-next-day", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.limits-funding-capacity-can-act-as-a-limit", "id": "rule.limits-funding-capacity-can-act-as-a-limit", "rail": "us-ach", "class": "Rule", "name": "Funding capacity can act as a limit", "statement": "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.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraph 5.3 with Appendix C", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.settlement-prefunding-where-a-reserve-bank-requires-it", "note": "The same prefunding provision, Operating Circular 4 paragraph 5.3 with Appendix C. That record states the provision itself, including the Reserve Bank stepping into the sending bank's settlement obligation; this one reads it as a limit, that the effective ceiling is then the settlement account balance rather than any rule figure, which that record does not say.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:limits by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "2022-03-18", "effective_to": null, "effective_note": "Split out of us-ach:limits by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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, "corroboration": [ { "source": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms paragraph 5.3, that a sending bank's Administrative Reserve Bank may require prefunding of credit item originations under Appendix C, and that credit item originations not prefunded when required may be rejected." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.settlement-prefunding-where-a-reserve-bank-requires-it", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.limits-how-the-operator-sees-the-limit", "id": "rule.limits-how-the-operator-sees-the-limit", "rail": "us-ach", "class": "Rule", "name": "How the operator sees the limit", "statement": "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.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraph 3.3(b)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:limits by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "2022-03-18", "effective_to": null, "effective_note": "Split out of us-ach:limits by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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, "corroboration": [ { "source": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:limits, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.limits-no-published-ceiling-on-non-same-day-entries", "id": "rule.limits-no-published-ceiling-on-non-same-day-entries", "rail": "us-ach", "class": "Rule", "name": "No published ceiling on non same day entries", "statement": "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.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "read in full", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.fedach-processing-schedule-2022-09-12", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-same-day-ach-limit-10-million", "section": "and the other Nacha public rule pages read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:limits by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "2022-03-18", "effective_to": null, "effective_note": "Split out of us-ach:limits by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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, "corroboration": [ { "source": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Read in full for a per entry dollar ceiling on an ordinary next day or two day ACH entry; none is stated anywhere in the circular's text." }, { "source": "us-ach:src.fedach-processing-schedule-2022-09-12", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Read in full for a per entry dollar ceiling on an ordinary next day or two day ACH entry; the schedule states transmission, distribution and settlement deadlines only and names no dollar ceiling." }, { "source": "us-ach:src.nacha-same-day-ach-limit-10-million", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that the rule changes described are limited to the Same Day ACH dollar ceiling and to the ARC, BOC, POP, RCK and XCK entry limits; it names no ceiling for an ordinary non same day ACH entry." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.limits-other-dollar-limits-exist-and-are-not-published", "id": "rule.limits-other-dollar-limits-exist-and-are-not-published", "rail": "us-ach", "class": "Rule", "name": "Other dollar limits exist and are not published", "statement": "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.", "rests_on": "rule", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-same-day-ach-limit-10-million", "section": "details section, read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:limits by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "2022-03-18", "effective_to": null, "effective_note": "Split out of us-ach:limits by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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, "corroboration": [ { "source": "us-ach:src.nacha-same-day-ach-limit-10-million", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that separate dollar limits for ARC, BOC, POP, RCK and XCK entries continue to apply alongside the Same Day ACH dollar limit change, without stating their values." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.limits-the-ceiling-that-is-coming", "id": "rule.limits-the-ceiling-that-is-coming", "rail": "us-ach", "class": "Rule", "name": "The ceiling that is coming", "statement": "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.", "rests_on": "rule", "facet": "limits", "parameters": { "limit": { "amount": 10000000, "currency": "USD", "per": "entry", "text": "$10,000,000 per payment" } }, "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-same-day-ach-limit-10-million", "section": "read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-abcs-of-ach", "section": "read 2026-09-17", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "supersedes", "to": "us-ach:rule.limits-the-same-day-ach-ceiling-today", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:limits by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. The typed parameters and the links other than sourced_from were added by the migration from the line's own words and are unchecked.", "confidence": "medium" }, "currency": { "effective_since": "2027-09-17", "effective_to": null, "effective_note": "Split out of us-ach:limits by the 2026-09 Orca Core migration; no rule change identified. The line itself dates this from 2027-09-17.", "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, "corroboration": [ { "source": "us-ach:src.nacha-same-day-ach-limit-10-million", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:limits, whose check against this source confirmed this detail line." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.limits-the-limit-a-sender-actually-hits", "id": "rule.limits-the-limit-a-sender-actually-hits", "rail": "us-ach", "class": "Rule", "name": "The limit a sender actually hits", "statement": "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.", "rests_on": "practice", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "us-ach:src.stripe-ach-direct-debit", "section": "read 2026-09-17, on blocked bank accounts and automatic retry caps", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "section": "on the bank's right to cancel ACH services for non compliance", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:limits by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "2022-03-18", "effective_to": null, "effective_note": "Split out of us-ach:limits by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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, "corroboration": [ { "source": "us-ach:src.stripe-ach-direct-debit", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms Stripe may block a bank account after a blockable ACH return until the issue causing the returns is resolved, and caps its own automatic retries of a failed payment at two within forty days." }, { "source": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the bank can transfer fines it receives for a customer's non compliance to that customer and cancel ACH services if the customer does not correct the non compliance issue." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.decision-points-what-a-bank-can-cap-in-operator-monitoring", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.limits-the-odfi-sets-an-exposure-limit-on-its-originator", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.limits-the-odfi-sets-an-exposure-limit-on-its-originator", "id": "rule.limits-the-odfi-sets-an-exposure-limit-on-its-originator", "rail": "us-ach", "class": "Rule", "name": "The ODFI sets an exposure limit on its originator", "statement": "A bank that originates is expected by its supervisor to fix a ceiling for each originator on both the credits and the debits it may send, to see whether that ceiling is still the right one and whether the originator is inside it, and to do so again and again rather than once at the start. The ceiling covers a single settlement day and the days that settle after it together, because entries already sent stay outstanding. Web debits are singled out for a limit of their own. The figure itself is the bank's to choose, and no figure is published for anyone.", "rests_on": "guidance", "facet": "limits", "relations": [ { "type": "sourced_from", "to": "us-ach:src.occ-bulletin-2006-39-ach-risk-management", "section": "the guidance on setting ACH credit and debit exposure thresholds for originators, reviewing them regularly, covering daily and multi day settlement periods, and the separate limit for WEB entries, read 2026-09-20", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.limits-the-limit-a-sender-actually-hits", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.decision-points-what-a-bank-can-cap-in-operator-monitoring", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "OCC Bulletin 2006-39, read 2026-09-20. This is supervisory guidance to national banks, which is why rests_on is guidance. [Unverified] The bulletin says a separate WEB limit follows a Nacha requirement, and it names no Nacha rule section; no public Nacha page read for this record states the exposure limit requirement in the Operating Rules, so the corpus does not say what the Operating Rules themselves require here.", "confidence": "medium" }, "currency": { "effective_since": "2006-09-01", "effective_to": null, "effective_note": "The date is the bulletin's own. The OCC page states the guidance remains in effect, with a 2025-03-20 amendment that removed its references to reputation risk and did not touch the exposure limit passage.", "source_edition": "OCC Bulletin 2006-39, dated 2006-09-01, as read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.occ-bulletin-2006-39-ach-risk-management", "checked_on": "2026-09-20", "checked_by": "validator-us-ach-core-2026-09-20", "notes": "Confirms banks should set ACH credit and debit exposure thresholds for each originator, monitor compliance with those thresholds on a regular basis, establish a separate exposure limit and monitoring practice for WEB entries consistent with NACHA requirements without naming a rule section, and monitor entries against the exposure limit across multiple settlement dates." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.participants-what-an-odfi-checks-before-an-originator-starts", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.limits-the-same-day-ach-ceiling-today", "id": "rule.limits-the-same-day-ach-ceiling-today", "rail": "us-ach", "class": "Rule", "name": "The Same Day ACH ceiling today", "statement": "$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.", "rests_on": "rule", "facet": "limits", "parameters": { "limit": { "amount": 1000000, "currency": "USD", "per": "entry", "text": "$1,000,000 per payment" } }, "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-same-day-ach-1-million-press-2022-03-18", "section": "read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:limits by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. The typed parameters and the links other than sourced_from were added by the migration from the line's own words and are unchecked.", "confidence": "medium" }, "currency": { "effective_since": "2022-03-18", "effective_to": "2027-09-17", "effective_note": "Split out of us-ach:limits by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's. The line's successor takes effect 2027-09-17.", "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, "corroboration": [ { "source": "us-ach:src.nacha-same-day-ach-1-million-press-2022-03-18", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the Same Day ACH per payment limit reached 1,000,000 dollars effective March 18, 2022." }, { "source": "us-ach:src.frb-same-day-ach-faq", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the 1,000,000 dollar value limit applies to a single item, not a batch, and that Treasury can originate and receive payments up to that limit at any of the Same Day ACH processing windows." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.limits-the-ceiling-that-is-coming", "type": "supersedes", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.same-day-government-entries", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.same-day-ineligible-entry-settles-next-day", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.messages-a-suspected-duplicate-file-waits-for-the-sender", "id": "rule.messages-a-suspected-duplicate-file-waits-for-the-sender", "rail": "us-ach", "class": "Rule", "name": "A suspected duplicate file waits for the sender", "statement": "Where a Reserve Bank tells a sending bank it has taken in what looks like a duplicate file, or any other problem with the file, it will not process that file until the sending bank or the sending bank's agent says to. Nothing in that obliges a Reserve Bank to catch a duplicate, since it may reject or set conditions on any item for any reason and takes on no duty to see that anyone else keeps the ACH rules. Where the duplicate got through and came from the Reserve Bank's own side, it may cancel the batch by originating a reversing batch and tell the sending bank it has done so.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraph 6.3, on notice of a suspected duplicate file and processing only with the sending bank's approval, read 2026-09-20", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.ach-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Federal Reserve Banks Operating Circular 4, effective 2026-01-05, paragraph 6.3, read 2026-09-20. The circular describes what the Reserve Bank does once it has notified the sender of a suspected duplicate or other problem; it does not describe how a suspected duplicate is detected, and this record makes no claim about that.", "confidence": "medium" }, "currency": { "effective_since": "2026-01-05", "effective_to": null, "effective_note": "The date is the effective date of the Operating Circular 4 edition read. Citation corrected 2026-09-21: removed reference to paragraph 13.2, which covers Reserve Bank-originated duplicates, not the sending bank's suspected duplicate described by paragraph 6.3.", "source_edition": "Federal Reserve Banks Operating Circular 4, effective 2026-01-05, read 2026-09-20", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-20", "checked_by": "validator-us-ach-core-2026-09-20", "notes": "Confirms paragraph 6.3: a Reserve Bank may reject or condition its processing of any item for any reason and does not assume responsibility for a sending bank's compliance with ACH rules; on notice of a suspected duplicate file or other problem, a Reserve Bank will not process the file without approval by the sending bank or its agent. Paragraph 13.2 confirms a Reserve Bank may cancel a duplicate or erroneous batch it originated by initiating a reversing batch and will notify the sending bank." } ] }, "source_class": "authoritative_primary", "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:state.held-at-the-operator", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.messages-character-handling-is-not-uniform-between", "id": "rule.messages-character-handling-is-not-uniform-between", "rail": "us-ach", "class": "Rule", "name": "Character handling is not uniform between operators", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-currently-accepted-characters", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:messages by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "2027-01-01", "effective_to": null, "effective_note": "Split out of us-ach:messages by the 2026-09 Orca Core migration; no rule change identified. The line itself dates this 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, "corroboration": [ { "source": "us-ach:src.nacha-currently-accepted-characters", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:messages, whose check against this source confirmed this detail line." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.format-field-fill-conventions", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.messages-correcting-the-data-rather-than-the-payment", "id": "rule.messages-correcting-the-data-rather-than-the-payment", "rail": "us-ach", "class": "Rule", "name": "Correcting the data rather than the payment", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "section": "originator responsibilities", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.treasury-green-book-2025-03", "section": "Notification of Change chapter", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:messages by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:messages by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the Rules require the originator to make the change requested by a Notification of Change within six banking days of receiving the information from the bank or before another entry is sent." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:exc.notification-of-change", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.noc-originator-applies-the-change", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.messages-reversal-is-a-field-value-not-a-message-type", "id": "rule.messages-reversal-is-a-field-value-not-a-message-type", "rail": "us-ach", "class": "Rule", "name": "REVERSAL is a field value, not a message type", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-reversals-and-enforcement", "section": "reversals rule effective 2021-06-30", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.recall-how-a-reversal-must-be-formatted", "note": "The same formatting rule from the same two sources. That record adds that other fields may change only as far as processing requires; this one adds that a reversal is an ordinary entry and that the rail carries no separate cancellation message.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:messages by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:messages by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.nacha-reversals-and-enforcement", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms a reversal must carry the word REVERSAL in the Company Entry Description field and keep the Company ID, SEC code and Amount fields identical to the original entry, with no separate message type for cancellation." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.format-batch-header-holds-what-entries-share", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.recall-how-a-reversal-must-be-formatted", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.messages-the-description-field-is-becoming-meaningful", "id": "rule.messages-the-description-field-is-becoming-meaningful", "rail": "us-ach", "class": "Rule", "name": "The description field is becoming meaningful", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-company-entry-descriptions", "section": "which names Appendix Three, Subpart 3.2.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "section": "upcoming revisions section", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:messages by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "2026-03-20", "effective_to": null, "effective_note": "Split out of us-ach:messages by the 2026-09 Orca Core migration; no rule change identified. The line itself dates this from 2026-03-20.", "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, "corroboration": [ { "source": "us-ach:src.nacha-company-entry-descriptions", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms from March 20, 2026 the Company Entry Description field carries PAYROLL for a PPD credit paying wages and PURCHASE for a consumer e-commerce debit normally using the WEB code, and that the ODFI has no obligation to verify PURCHASE is used correctly." }, { "source": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the new PAYROLL and PURCHASE standard company entry descriptions effective March 20, 2026 and that the ODFI has no obligation to verify the presence or accuracy of PURCHASE." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.format-batch-header-holds-what-entries-share", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.messages-the-operator-acknowledges-a-file-it-has-taken-in", "id": "rule.messages-the-operator-acknowledges-a-file-it-has-taken-in", "rail": "us-ach", "class": "Rule", "name": "The operator acknowledges a file it has taken in", "statement": "A Reserve Bank sends the sending bank an acknowledgement that it has received an ACH file by electronic transmission and has put it through limited processing. That is all the acknowledgement says: it is not acceptance of the items, and the Reserve Bank may still reject any of them afterwards. The duty then runs the other way, since the sending bank must check what the acknowledgement reports and raise any discrepancy at once, and must say promptly when an acknowledgement it expected never came. Alongside it a bank can see the status, dollar confirmation and batch and item counts of the files it has sent and received.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraph 6.4, on the acknowledgement, what it does not mean, and the sending bank's duty to check it and to report a missing one, read 2026-09-20", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-fedach-origination-and-receipt", "section": "the service page's description of file status, dollar confirmation and batch and item count verification on input and output files, read 2026-09-20", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.ach-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Federal Reserve Banks Operating Circular 4, effective 2026-01-05, paragraph 6.4, and the operator's FedACH Origination and Receipt service page, both read 2026-09-20. [Unverified] Neither document read gives the acknowledgement's record layout or its field names.", "confidence": "medium" }, "currency": { "effective_since": "2026-01-05", "effective_to": null, "effective_note": "The date is the effective date of the Operating Circular 4 edition read. The acknowledgement itself is long-standing; this edition is the one consulted.", "source_edition": "Federal Reserve Banks Operating Circular 4, effective 2026-01-05; FedACH Origination and Receipt service page as read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-20", "checked_by": "validator-us-ach-core-2026-09-20", "notes": "Confirms paragraph 6.4: the acknowledgment reports that a Reserve Bank has received the file and performed limited processing, is not acceptance and does not bar a later rejection of items, and the sending bank must verify the acknowledgment, report a discrepancy at once and report promptly when an expected acknowledgment does not arrive." }, { "source": "us-ach:src.frb-fedach-origination-and-receipt", "checked_on": "2026-09-20", "checked_by": "validator-us-ach-core-2026-09-20", "notes": "Confirms FedACH Services via FedLine Web gives a bank access to file status, dollar confirmation and batch and item count verification on the files it has sent and received." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:state.awaiting-settlement", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.messages-the-record-line", "id": "rule.messages-the-record-line", "rail": "us-ach", "class": "Rule", "name": "The record line", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-currently-accepted-characters", "section": "read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:messages by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "2027-01-01", "effective_to": null, "effective_note": "Split out of us-ach:messages by the 2026-09 Orca Core migration; no rule change identified. The line itself dates this 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, "corroboration": [ { "source": "us-ach:src.nacha-currently-accepted-characters", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:messages, whose check against this source confirmed this detail line." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.format-file-header-and-control", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-record-line-ending", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.messages-the-record-types-a-payment-uses", "id": "rule.messages-the-record-types-a-payment-uses", "rail": "us-ach", "class": "Rule", "name": "The record types a payment uses", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "us-ach:src.treasury-green-book-2025-03", "section": "Returns chapter", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-currently-accepted-characters", "section": "which speaks of the ACH Record", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:messages by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:messages by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.treasury-green-book-2025-03", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that when a return entry is prepared, the original Company or Batch Header Record, the original Entry Detail Record and the Company or Batch Control Record are copied for return to the Originator, quoting this from the Nacha Operating Rules and Guidelines." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.format-file-header-and-control", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-return-entry-construction", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.messages-the-standard-entry-class-code", "id": "rule.messages-the-standard-entry-class-code", "rail": "us-ach", "class": "Rule", "name": "The Standard Entry Class code", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "us-ach:src.stripe-ach-sec-codes", "section": "read 2026-09-17", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraph 3.3(b), which excludes IAT and ENR from same day settlement by code", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:messages by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:messages by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:messages, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.format-batch-header-holds-what-entries-share", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.messages-the-travel-rule-threshold-and-what-an-iat-carries", "id": "rule.messages-the-travel-rule-threshold-and-what-an-iat-carries", "rail": "us-ach", "class": "Rule", "name": "The travel rule threshold and what an IAT carries", "statement": "The Bank Secrecy Act sets its travel rule at 3,000 dollars: at or above that figure the institution sending a transmittal order has to put the transmittor's name, the account the payment came from, the amount, the execution date, the receiving institution's identity and whatever recipient details came with the order into the order it passes on, together with its own name and address or number, and an intermediary has to carry forward what it received. That threshold does not govern what an IAT entry carries, because the ACH rules ask for the same party information on every IAT whatever its size. The regulation also lifts the duty off certain transfers altogether, among them those where both ends are banks, brokers, mutual funds or government bodies, and those moving between one person's own accounts at a single bank.", "rests_on": "law", "facet": "messages", "parameters": { "limit": { "amount": 3000, "currency": "USD", "per": "entry", "text": "The travel rule bites on a transmittal of funds of 3,000 dollars or more. It sets no floor for what an IAT entry must carry." } }, "relations": [ { "type": "sourced_from", "to": "us-ach:src.ecfr-31-cfr-1010-410", "section": "paragraph (f), on what a transmittor's financial institution and an intermediary must include in a transmittal order of 3,000 dollars or more, and paragraph (f)(4), which points the exceptions at paragraph (e)(6) and at 31 CFR 1020.410(a)(6), read 2026-09-20", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.ecfr-31-cfr-1020-410", "section": "paragraph (a)(6), the list of funds transfers the section does not reach, read 2026-09-20", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-2021-03-09", "section": "question 12, on whether travel rule information is needed for every IAT or only above 3,000 dollars, read 2026-09-20", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "31 CFR 1010.410(f) and 31 CFR 1020.410(a)(6) from the eCFR, and Nacha's IAT FAQs revised 2021-03-09 for the point that the ACH rules ask for the information on every IAT, all read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "2016-11-04", "effective_to": null, "effective_note": "The date is the latest amendment named in the source note to 31 CFR 1010.410. The 3,000 dollar figure is older than that amendment, and no source read here gives the date it was set.", "source_edition": "31 CFR 1010.410 and 31 CFR 1020.410, current text on ecfr.gov as read 2026-09-20; Nacha IAT FAQs revised 2021-03-09", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.ecfr-31-cfr-1010-410", "checked_on": "2026-09-20", "checked_by": "validator-us-ach-core-2026-09-20", "notes": "Confirms paragraph (f) requires a transmittor's financial institution to include name, account number, address, amount, execution date, receiving institution identity and recipient details in a transmittal order of 3,000 dollars or more, an intermediary institution to carry forward what it received, and paragraph (f)(4) points its exceptions to paragraph (e)(6) and to 31 CFR 1020.410(a)(6); the section's note shows the 3,000 dollar figure amended through Nov. 4, 2016." }, { "source": "us-ach:src.ecfr-31-cfr-1020-410", "checked_on": "2026-09-20", "checked_by": "validator-us-ach-core-2026-09-20", "notes": "Confirms paragraph (a)(6) excepts funds transfers where both originator and beneficiary are a bank, a wholly owned domestic subsidiary of a bank or of a securities broker or dealer, a futures commission merchant, the United States, a state or local government or agency, or a mutual fund, and transfers between the same person's accounts at the same bank." }, { "source": "us-ach:src.nacha-iat-faqs-2021-03-09", "checked_on": "2026-09-20", "checked_by": "validator-us-ach-core-2026-09-20", "notes": "Confirms question 12's statement that while the Bank Secrecy Act only requires travel rule information when a funds transfer exceeds 3,000 dollars, the ACH Rules require this information for all IAT entries regardless of size." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.messages-traffic-that-moves-no-money", "id": "rule.messages-traffic-that-moves-no-money", "rail": "us-ach", "class": "Rule", "name": "Traffic that moves no money", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraphs 2.1(j) and 19.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:messages by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:messages by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:messages, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.prenote-optional-zero-dollar-entry", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.messages-what-identifies-an-entry-afterwards", "id": "rule.messages-what-identifies-an-entry-afterwards", "rail": "us-ach", "class": "Rule", "name": "What identifies an entry afterwards", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "us-ach:src.treasury-green-book-2025-03", "section": "trace number description and the four fields a return must match", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:messages by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:messages by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.treasury-green-book-2025-03", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms a trace number is a fifteen digit number, with the ODFI's routing number as the first eight digits and a unique item number as the last seven, included in the Entry Detail, Corporate Entry Detail and Entry Detail Addenda records, and that a return must match it along with three other fields against the original." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.format-trace-number-assignment", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.messages-who-defines-the-format", "id": "rule.messages-who-defines-the-format", "rail": "us-ach", "class": "Rule", "name": "Who defines the format", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraph 3.3(a)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:messages by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:messages by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:messages, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.micro-entries-amounts-and-timing", "id": "rule.micro-entries-amounts-and-timing", "rail": "us-ach", "class": "Rule", "name": "Micro-entries: offsetting debits and settlement together", "statement": "Debit micro-entries may not add up to more than the credit micro-entries they offset, so the Receiver's account is never left with a net debit. Credits and their offsetting debits go in the same processing window with the same Effective Entry Date, so they settle at the same time. A debit micro-entry cannot be sent without its credits, and an Originator may not deliver the credits by another channel, such as a card or real time payment, while taking the offset by ACH.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.micro-entry", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-micro-entries-phase-1", "section": "Details and FAQs; read 2026-09-19", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.micro-entries-definition-and-labels", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Nacha's public rule pages and FAQs for Micro-Entries Phase 1 and Phase 2, read 2026-09-19, and the other sources its sourced_from links name; the Nacha Operating Rules text was not consulted.", "confidence": "medium" }, "currency": { "effective_since": "2022-09-16", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from the public sources its sourced_from links name; no rule change identified after the date given.", "source_edition": "Nacha public rule pages read 2026-09-19; Nacha Operating Rules not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-micro-entries-phase-1", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that debit micro-entries cannot exceed their offsetting credits, that both must carry the same effective entry date for simultaneous settlement, and that a debit micro-entry cannot be sent alone or used to offset a credit delivered through another channel." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.micro-entries-definition-and-labels", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.micro-entries-definition-and-labels", "id": "rule.micro-entries-definition-and-labels", "rail": "us-ach", "class": "Rule", "name": "Micro-entries: what they are and how they are labelled", "statement": "Since 2022-09-16 the rules define a micro-entry as an ACH credit of less than $1, together with any offsetting debits, whose purpose is account verification: confirming the Receiver's account, or that a person can get into it. Micro-entries carry ACCTVERIFY in the Company Entry Description. The Company Name should be one the Receiver will know on sight, matching or nearly matching the name its later entries will carry; small differences needed for processing are allowed. The rule standardizes micro-entries; it does not require anyone to use them.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.micro-entry", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-micro-entries-phase-1", "section": "Details and FAQs; read 2026-09-19", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.tompkins-originating-ach-quick-reference", "section": "Originating WEB Entries: micro-entry description and company name", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.micro-entries-amounts-and-timing", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Nacha's public rule pages and FAQs for Micro-Entries Phase 1 and Phase 2, read 2026-09-19, and the other sources its sourced_from links name; the Nacha Operating Rules text was not consulted.", "confidence": "medium" }, "currency": { "effective_since": "2022-09-16", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from the public sources its sourced_from links name; no rule change identified after the date given.", "source_edition": "Nacha public rule pages read 2026-09-19; Nacha Operating Rules not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-micro-entries-phase-1", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the 2022-09-16 effective date, the definition of a micro-entry as a credit under one dollar plus its offsetting debits for account verification, the required ACCTVERIFY company entry description, and the Company Name matching requirement with minor variations allowed." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.micro-entries-amounts-and-timing", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.micro-entries-fraud-monitoring", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.practice-instant-verification-and-micro-deposits", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.micro-entries-fraud-monitoring", "id": "rule.micro-entries-fraud-monitoring", "rail": "us-ach", "class": "Rule", "name": "Micro-entries: fraud detection by monitoring volumes", "statement": "From 2023-03-17 an Originator of micro-entries must use commercially reasonable fraud detection that, at the least, tracks the forward and return volumes of its micro-entries, so it knows what normal activity looks like and can see when activity departs from it. It does not have to validate the account behind each micro-entry or review them one by one.", "rests_on": "rule", "facet": "liability", "relations": [ { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.micro-entry", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-micro-entries-phase-2", "section": "Details; read 2026-09-19", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.micro-entries-definition-and-labels", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Nacha's public rule pages and FAQs for Micro-Entries Phase 1 and Phase 2, read 2026-09-19, and the other sources its sourced_from links name; the Nacha Operating Rules text was not consulted.", "confidence": "medium" }, "currency": { "effective_since": "2023-03-17", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from the public sources its sourced_from links name; no rule change identified after the date given.", "source_edition": "Nacha public rule pages read 2026-09-19; Nacha Operating Rules not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-micro-entries-phase-2", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the 2023-03-17 effective date and that the required fraud detection is monitoring of forward and return volumes to establish a baseline, not individual account validation or entry-by-entry review." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.micro-entries-receiver-confirmation", "id": "rule.micro-entries-receiver-confirmation", "rail": "us-ach", "class": "Rule", "name": "Micro-entries: authorization and the Receiver's confirmation before live entries", "statement": "The Receiver authorizes micro-entries, though the Originator need not disclose their exact amounts beforehand and may describe them only in general terms, such as under $1. Before live entries are sent, the Receiver must confirm the micro-entry details back to the Originator; the absence of a return or complaint is not a confirmation.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.micro-entry", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-micro-entries-phase-1", "section": "FAQs; read 2026-09-19", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-supplementing-fraud-detection-web-debits", "section": "FAQs: micro-entries; read 2026-09-19", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.web-validation-prenote-and-micro-entry-results", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Nacha's public rule pages and FAQs for Micro-Entries Phase 1 and Phase 2, read 2026-09-19, and the other sources its sourced_from links name; the Nacha Operating Rules text was not consulted.", "confidence": "medium" }, "currency": { "effective_since": "2022-09-16", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from the public sources its sourced_from links name; no rule change identified after the date given.", "source_edition": "Nacha public rule pages read 2026-09-19; Nacha Operating Rules not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-supplementing-fraud-detection-web-debits", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that a Receiver must confirm micro-entry amounts back to the Originator before live entries follow, and that the absence of a return or complaint from the RDFI is not itself a confirmation." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.web-validation-prenote-and-micro-entry-results", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.no-reinitiation-without-new-authorization", "id": "rule.no-reinitiation-without-new-authorization", "rail": "us-ach", "class": "Rule", "name": "No reinitiation of an unauthorized or revoked debit", "statement": "An Originator does not send again a debit that came back because the Receiver said it was unauthorized or had revoked the authorization. Any new debit needs a new authorization, obtained and kept before it is sent.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the retry guidance of us-ach:R05, us-ach:R07, us-ach:R10 and us-ach:R29 by the 2026-09 Orca Core migration; the claim is theirs. No source has been checked for it.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms it is a violation of the Rules to re-initiate a debit entry if a return is received for any reason other than NSF or uncollected funds, or a stop payment return re-presented with payee approval, which covers the unauthorized and revoked authorization return reasons." }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms for R07, authorization revoked by consumer, that the ODFI should not resubmit the entry without a new authorization." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.return-re-presenting-a-failed-debit", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.returned", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R05", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R07", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R10", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R29", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.noc-corrected-data-layout", "id": "rule.noc-corrected-data-layout", "rail": "us-ach", "class": "Rule", "name": "Where the corrected data sits in an NOC", "statement": "Each value in the corrected data field of an NOC is left justified at a fixed start position, and the gaps between values are spaces. The routing number is always 9 digits including the check digit. Where both are sent, C03 puts the account number from position 13 after three spaces, C06 puts the transaction code at positions 21 and 22 after an account number of up to 17 positions, and C07 packs routing number, account number and transaction code into positions 1 to 9, 10 to 26 and 27 to 28. C01 uses the first 17 positions, C05 the first 2. C13 carries no corrected data.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "applies_to", "to": "us-ach:txn.cor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.commerce-bank-ach-return-noc-tran-codes-2022-11", "section": "NOC codes, description column", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "section": "NOC reason codes, pages 15 and 16", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "section": "Notifications of Change, change field entry procedures", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Commerce Bank code table (2022) gives every position; Jefferson Bank (March 2022) and CBS Bank (March 2025) agree for C01, C06 and C07 and describe C02, C03 and C05 as change fields. Read 2026-09-19. For C08 and C09 the sources give different field lengths, so they are left out. The record format itself is in the paid rulebook and was not read.", "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": "us-ach:src.commerce-bank-ach-return-noc-tran-codes-2022-11", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the corrected data field positions for C01 (first 17 positions), C02 (first 9), C03 (first 9 then account number at position 13 through 29 with a space in positions 10 through 12), C05 (first 2), C06 (account number in first 17, transaction code at 21 and 22 with spaces in 18 through 20) and C07 (routing number 1 through 9, account number 10 through 26, transaction code 27 and 28)." }, { "source": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the C01 corrected account number appears left justified in the first 17 positions of the Corrected Data Field, and the C02 corrected routing number including check digit appears in the first 9 positions." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:C01", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C05", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C06", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C07", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C08", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C09", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C13", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C65", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.noc-federal-agencies-accept-six-codes", "id": "rule.noc-federal-agencies-accept-six-codes", "rail": "us-ach", "class": "Rule", "name": "Federal agencies act on six NOC codes only", "statement": "Federal government payers process only C01, C02, C03, C05, C06 and C07, and recognise only the checking, savings and general ledger transaction codes on them. An NOC is usually applied by the next payment, though some take two payment cycles. Only SSA, RRB and OPM send refused NOCs, using C64 to C69.", "rests_on": "guidance", "facet": "messages", "relations": [ { "type": "binds", "to": "us-ach:role.federal-government-agency", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.treasury-green-book-2025-03", "section": "Notification of Change chapter, sections A and C", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Treasury Green Book (2025-03), Notification of Change chapter, read 2026-09-19.", "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": "us-ach:src.treasury-green-book-2025-03", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms federal disbursing systems process only the C01, C02, C03, C05, C06 and C07 change codes and recognize only the checking, savings and general ledger transaction codes on them, that a change is generally applied by the next payment though some take two payment cycles, and that only the Social Security Administration, the Railroad Retirement Board and the Office of Personnel Management use refused change codes C64 through C69." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:C64", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C65", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C66", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C67", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C68", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C69", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.noc-more-than-one-per-entry", "id": "rule.noc-more-than-one-per-entry", "rail": "us-ach", "class": "Rule", "name": "More than one NOC can be sent for one entry", "statement": "The FedACH derive tool lets an RDFI create several NOCs against the same forward entry, for example when different change codes are needed, and shows the changes already sent for it. The public sources read state no Nacha limit on the number of NOCs per entry.", "rests_on": "practice", "facet": "messages", "relations": [ { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-derived-returns-nocs-faq", "section": "answer on multiple NOCs for the same forward item", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Federal Reserve Financial Services FAQ on derived returns and NOCs, read 2026-09-19. What the Nacha rules say about repeat NOCs was not found.", "confidence": "low" }, "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": "us-ach:src.frb-derived-returns-nocs-faq", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms multiple NOCs can be derived for the same forward item, for example when different change codes are needed, and that the tool displays all previous changes made to the item." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.noc-odfi-passes-it-on-within-2-banking-days", "id": "rule.noc-odfi-passes-it-on-within-2-banking-days", "rail": "us-ach", "class": "Rule", "name": "The ODFI passes an NOC to the Originator within 2 banking days", "statement": "An ODFI that receives an NOC must give the Originator the change information within 2 banking days of the NOC's settlement date.", "rests_on": "rule", "facet": "messages", "parameters": { "time_window": { "count": 2, "unit": "banking_day", "from": "settlement_date", "text": "2 banking days after the settlement date of the NOC" } }, "relations": [ { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "section": "Notification of Change (NOC), page 15", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "section": "Notifications of Change introduction", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Jefferson Bank Obligations of Originators (March 2022) states the 2 banking days from the NOC's settlement date; CBS Bank (March 2025) states two days without saying from when. Read 2026-09-19.", "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": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms ODFIs must report NOC information to Originators within two banking days from the settlement date of the NOC." }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the ODFI must pass NOC information on to the Originator within two days of the NOC." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:exc.notification-of-change", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.noc-originator-applies-the-change", "id": "rule.noc-originator-applies-the-change", "rail": "us-ach", "class": "Rule", "name": "The Originator applies an NOC within 6 banking days or before the next entry", "statement": "An Originator must make the change an NOC asks for within 6 banking days of receiving the change information, or before it sends the next entry to that account, whichever comes later. Jefferson Bank adds that an Originator of a single entry payment need not make the change. The sources disagree on the edges: CBS Bank says whichever is earlier, and Bank of North Dakota gives 3 banking days.", "rests_on": "rule", "facet": "messages", "parameters": { "time_window": { "count": 6, "unit": "banking_day", "from": "receipt", "text": "6 banking days after receiving the NOC, or before the next entry if that is later" } }, "relations": [ { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.fhb-ach-noc-reason-codes", "section": "introductory paragraph, citing Nacha rules subsection 2.11.1", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "section": "Notification of Change (NOC), page 15", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "section": "originator responsibilities", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "section": "Notifications of Change introduction, which says whichever is earlier", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.bank-of-north-dakota-ach-overview-2024", "section": "notification of change, which says three banking days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.messages-correcting-the-data-rather-than-the-payment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "First Hawaiian Bank and Jefferson Bank state 6 banking days or the next entry, whichever is later; Popular Bank states 6 banking days or before another entry without saying which governs; CBS Bank says whichever is earlier; Bank of North Dakota says 3 banking days. Read 2026-09-19. The majority reading is taken and the disagreement is kept in the statement.", "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": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms Originators of recurring entries must make the specified changes within six banking days of receipt of the NOC information or before initiating another entry to the account, whichever is later, and that Originators of single entry payments are not required to make the change." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:exc.notification-of-change", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C01", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C05", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C06", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C07", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C08", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C09", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C13", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C14", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.noc-rdfi-warrants-the-corrected-data", "id": "rule.noc-rdfi-warrants-the-corrected-data", "rail": "us-ach", "class": "Rule", "name": "The RDFI warrants the data in its NOC", "statement": "By sending an NOC the RDFI warrants that the corrected information in it is right, so an Originator that applies it is relying on the RDFI's promise.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "section": "Notification of Change (NOC), page 15", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "section": "Notification of Change paragraph", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Jefferson Bank Obligations of Originators (March 2022) and Popular Bank ACH Rules Awareness Guide (revised 2025-04-02), read 2026-09-19.", "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": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that by initiating an NOC the RDFI warrants that the information it sends in the NOC is correct." }, { "source": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the Receiving Bank warrants that the Notification of Change information it provides is correct." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:exc.notification-of-change", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C01", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C05", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C06", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C07", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C08", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C09", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C13", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.noc-same-day-and-fee", "id": "rule.noc-same-day-and-fee", "rail": "us-ach", "class": "Rule", "name": "NOCs can settle same day and carry no Same Day Entry Fee", "statement": "FedACH treats NOCs (COR entries) as eligible for same day processing without charging the Same Day Entry Fee, and under the Nacha rules they settle at the earliest opportunity. Prenotifications differ: they are forward entries and are charged the fee.", "rests_on": "guidance", "facet": "settlement", "relations": [ { "type": "binds", "to": "us-ach:role.ach-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.cor", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-same-day-ach-faq", "section": "answers on NOCs and on prenotification entries", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Federal Reserve Financial Services Same Day ACH FAQ, read 2026-09-19. It reports the Nacha settlement rule; the rulebook was not consulted.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "As published by the Federal Reserve on 2026-09-19; the page carries no effective date.", "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": "us-ach:src.frb-same-day-ach-faq", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms NOCs are eligible for same day processing and will not be assessed the Same Day Entry Fee because they settle at the earliest opportunity, while prenotification entries are forward entries eligible for same day settlement and are assessed the fee." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.same-day-entry-fee", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.same-day-returns-regardless-of-forward", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.noc-window-2-banking-days", "id": "rule.noc-window-2-banking-days", "rail": "us-ach", "class": "Rule", "name": "Notification of change: 2 banking days after the entry settles", "statement": "An RDFI that sends an NOC must send it within 2 banking days of the settlement date of the entry it corrects. NOCs caused by a merger, acquisition or a similar event at the RDFI are outside that limit.", "rests_on": "rule", "facet": "messages", "parameters": { "time_window": { "count": 2, "unit": "banking_day", "from": "settlement_date", "text": "2 banking days after the settlement date of the original entry (merger and similar NOCs excepted)" } }, "relations": [ { "type": "part_of", "to": "us-ach:exc.notification-of-change", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.gateway", "note": "The sources name the RDFI; C14 is sent by a Gateway, which is read as held to the same window. [Inference]", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "section": "Notifications of Change introduction", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.bmo-ach-return-reason-codes-2025-05", "section": "NOC reason code table, time frame column", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.commerce-bank-ach-return-noc-tran-codes-2022-11", "section": "NOC codes, time frame column", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "section": "Notification of Change (NOC), page 15", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.bank-of-north-dakota-ach-overview-2024", "section": "notification of change", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Five independent public guides (CBS Bank, BMO, Commerce Bank, Jefferson Bank, Bank of North Dakota) state the 2 banking day window; the merger exception is in CBS Bank and Bank of North Dakota. Read 2026-09-19. The Nacha Operating Rules were 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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that with the exception of NOCs due to a merger, acquisition or similar event, an NOC must be transmitted within two banking days of the settlement date of the entry it relates to." }, { "source": "us-ach:src.bank-of-north-dakota-ach-overview-2024", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms an NOC must be generated within two banking days of the original settlement date of the entry, unless the NOC is being generated based on a merger or acquisition." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:exc.notification-of-change", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C01", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C02", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C03", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C05", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C06", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C07", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C08", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C09", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C13", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C14", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.odfi-oversight-of-third-party-senders", "id": "rule.odfi-oversight-of-third-party-senders", "rail": "us-ach", "class": "Rule", "name": "ODFI oversight of Third-Party Senders", "statement": "An ODFI must know how each customer uses the network, whether as Originator, Third-Party Sender or another kind of intermediary, and must apply its risk management duties to intermediaries whatever role they hold on a given entry, weighing the extra risk, including the intermediary's failure; banking regulators expect more diligence where nested processors are allowed. In practice that means registering its senders with Nacha, knowing whether they allow nested senders, keeping audit and termination rights in its agreements, and staying answerable for the entries, including taking back extended returns if a sender collects a consumer debit and never passes the money on. It need not review a sender's own risk assessment.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-ops-bulletin-2-2014-third-party-senders", "section": "Discussion, pages 2 and 3, citing Subsection 2.2.3 ODFI Risk Management in the 2015 rules; Tuition Processing notes on incomplete transactions and nested processors, pages 7 and 8", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-third-party-sender-registration", "section": "FAQs", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-third-party-sender-roles", "section": "Impact", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-third-party-sender-identification-tool", "section": "introduction", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.tps-registration", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.participants-agents-are-allowed-and-the-bank-still-owns-the", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted. The subsection number is from the 2015 rules cited by the bulletin [Unverified: current numbering].", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Guidance of 2014-12-30 with later additions from the rules effective 2017-09-29 and 2022-09-30.", "source_edition": "Nacha public pages and ACH Operations Bulletin #2-2014, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-ops-bulletin-2-2014-third-party-senders", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms an ODFI must perform diligence and monitoring of a payment intermediary's ACH activity whatever role it holds on a given entry, weighing the risks the intermediary creates including the risk of its failure, citing Subsection 2.2.3 ODFI Risk Management of the 2015 rules; and confirms, in the bulletin's tuition processor scenario, that the ODFI is ultimately responsible for accepting an Extended Return Entry when the processor fails to remit collected funds to the university, whether from technical failure, bankruptcy, fraud or embezzlement. The registration and nested sender identification duties are confirmed separately against Nacha's registration and roles pages." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.tps-duties-and-warranties", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.tps-registration", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.operator-derives-dishonors-and-contests", "id": "rule.operator-derives-dishonors-and-contests", "rail": "us-ach", "class": "Rule", "name": "FedACH can create dishonored and contested dishonored returns one at a time", "statement": "An RDFI or ODFI without its own file software can create a single dishonored or contested dishonored return in FedLine Web by picking the item, the type and the reason code. The same tool creates single returns, NOCs and refused NOCs; the Reserve Banks let only the depository institution itself, not a third-party processor, use it for returns and NOCs.", "rests_on": "guidance", "facet": "return", "relations": [ { "type": "binds", "to": "us-ach:role.ach-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-derived-returns-nocs-faq", "section": "answers on dishonored and contested items, refusing an NOC, and third-party processing", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Federal Reserve Financial Services FAQ on derived returns and NOCs, read 2026-09-19. It describes an operator service, not a Nacha rule.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Describes the FedLine Web service as published on 2026-09-19; the page carries no effective date.", "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": "us-ach:src.frb-derived-returns-nocs-faq", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms a dishonored or contested dishonored return, and a refused NOC, can each be derived in FedLine Web by selecting the item type, entering identifying details and the reason or change code, and that only the RDFI itself, not a third party processor, may process returns and NOCs this way." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.participants-only-the-receiving-bank-may-derive-a-return-or-noc", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.overall-return-rate-threshold", "id": "rule.overall-return-rate-threshold", "rail": "us-ach", "class": "Rule", "name": "Overall return rate level: 15 percent", "statement": "An Originator's rate of debit returns for any reason above 15 percent triggers an inquiry.", "rests_on": "rule", "facet": "return", "parameters": { "limit": { "rate": 15, "unit": "percent", "measured_over": "debit entries over the preceding 60 days [Unverified]", "text": "15%" } }, "relations": [ { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the rates block of corpus/us-ach/meta.json and the counts_toward lists of the us-ach codes by the 2026-09 Orca Core migration. No source has been checked for it.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.bank-of-north-dakota-ach-overview-2024", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the overall return rate level is defined as an overall return rate of fifteen percent, covering debit entries returned for any reason excluding RCK entries." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R01", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R02", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R03", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R04", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R05", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R06", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R07", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R08", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R09", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R10", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R11", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R12", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R13", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R14", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R15", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R16", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R17", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R18", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R19", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R20", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R21", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R22", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R24", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R25", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R26", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R27", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R28", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R29", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R30", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R31", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R32", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R33", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R34", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R35", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R37", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R38", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R39", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R50", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R51", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R52", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R53", "type": "counts_toward", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.participants-a-correspondents-account-can-be-used-and-it", "id": "rule.participants-a-correspondents-account-can-be-used-and-it", "rail": "us-ach", "class": "Rule", "name": "A correspondent's account can be used, and it changes nothing", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraph 9.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:participants by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:participants by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:participants, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.participants-a-wrong-account-type-code-is-corrected-not-refused", "id": "rule.participants-a-wrong-account-type-code-is-corrected-not-refused", "rail": "us-ach", "class": "Rule", "name": "A wrong account type code is corrected, not refused", "statement": "An entry coded for one kind of account that reaches an account of another kind, a savings credit landing on a checking account for instance, is still an entry the account number identifies, so the receiving bank may post it and tell the sender the right transaction code through a Notification of Change. The alternative is a return, and a return here means the account number found nothing (R03) or the account cannot take that kind of entry at all (R20), not that the code and the account disagreed.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-ops-bulletin-2-2024-individual-name", "section": "the bulletin's statement that posting may rest on the account number, citing Nacha Operating Rules subsection 3.1.2, read 2026-09-20", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "us-ach:exc.notification-of-change", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:C05", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R20", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Nacha's public ACH Operations Bulletin 2-2024 for the posting rule. [Inference] That a mismatched transaction code is handled with a C05 Notification of Change rather than a return follows from the corpus's own C05 record, whose meaning is the wrong kind of account, read together with the posting rule; no source read for this record states the two together, and which of posting with a C05 or returning a given entry a receiving bank takes is its own decision.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Neither the posting rule nor the C05 code carries a start date in the sources read, so this is recorded as long-standing.", "source_edition": "Nacha ACH Operations Bulletin 2-2024, dated 2024-07-22, read 2026-09-20", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.participants-agents-are-allowed-and-the-bank-still-owns-the", "id": "rule.participants-agents-are-allowed-and-the-bank-still-owns-the", "rail": "us-ach", "class": "Rule", "name": "Agents are allowed and the bank still owns the outcome", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraph 3.5", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:participants by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:participants by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:participants, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.odfi-oversight-of-third-party-senders", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.participants-gateway-screening-does-not-move-the-duty", "id": "rule.participants-gateway-screening-does-not-move-the-duty", "rail": "us-ach", "class": "Rule", "name": "Gateway screening does not move the duty", "statement": "The Federal Reserve screens an inbound international entry only where it is acting as Gateway Operator on its own FedGlobal service; as an ACH Operator handling other participants' traffic it takes on no screening duty at all. What the Gateway does with a hit is write it down, not act on it: it sets the Gateway Operator screening indicator in the entry detail record to one where the entry may match and zero where it does not, and holds, pends or rejects nothing on that account. The receiving bank carries the responsibility either way and still has to do its own work on the entry. Cross-border tightens rather than loosens this: on an inbound entry the receiving bank answers for compliance, and on an outbound one the originating bank cannot lean on screening by a receiving institution outside the United States and is expected to look harder itself.", "rests_on": "law", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-iat-faqs", "section": "the answers on when the Federal Reserve screens as Gateway Operator and not as ACH Operator, on the screening indicator in field 10 of the entry detail record, and on the receiving institution's own responsibility, read 2026-09-20", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.ffiec-bsa-aml-ofac-overview", "section": "the Screening ACH transactions passage on cross-border entries inbound and outbound, read 2026-09-20", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-2021-03-09", "section": "question 16 on funds availability while an OFAC review runs and question 33 on screening before rather than after posting, read 2026-09-20", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.gateway", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The Federal Reserve Financial Services IAT FAQ, the FFIEC BSA/AML OFAC chapter as posted by OFAC, and Nacha's IAT FAQ revised 2021-03-09, all read 2026-09-20. Three sources on three hosts say the same thing about where the duty sits.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "None of the three sources dates the allocation of the screening duty, so it is recorded as long-standing.", "source_edition": "Federal Reserve Financial Services IAT FAQ as read 2026-09-20; FFIEC BSA/AML Examination Manual OFAC overview, pages footed 8/24/2007; Nacha IAT FAQs revised 2021-03-09", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.frb-iat-faqs", "checked_on": "2026-09-20", "checked_by": "validator-us-ach-core-2026-09-20", "notes": "Confirms the Federal Reserve screens inbound IAT items only in its capacity as a gateway operator on FedGlobal Services, is not obligated to screen items as an ACH operator, populates field 10 of the entry detail record with a 1 for a possible match or 0 for no match, and will not hold, pend or reject any IAT item; also confirms the receiving institution still bears responsibility for OFAC compliance." }, { "source": "us-ach:src.ffiec-bsa-aml-ofac-overview", "checked_on": "2026-09-20", "checked_by": "validator-us-ach-core-2026-09-20", "notes": "Confirms that for inbound cross-border ACH transactions the RDFI is responsible for OFAC compliance, and for outbound cross-border ACH transactions the ODFI cannot rely on screening by a receiving institution outside the United States and must exercise increased diligence." }, { "source": "us-ach:src.nacha-iat-faqs-2021-03-09", "checked_on": "2026-09-20", "checked_by": "validator-us-ach-core-2026-09-20", "notes": "Confirms question 33's guidance to screen an IAT before posting rather than after, and question 16's statement that funds availability may be delayed while an RDFI clears a suspect OFAC finding." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.decision-points-what-a-false-positive-is-on-a-sanctions-screen", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.participants-new-duties-reach-originators-and-service", "id": "rule.participants-new-duties-reach-originators-and-service", "rail": "us-ach", "class": "Rule", "name": "New duties reach originators and service providers directly", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-fraud-monitoring-phase-1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-fraud-monitoring-phase-2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:participants by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "2026-03-20", "effective_to": null, "effective_note": "Split out of us-ach:participants by the 2026-09 Orca Core migration; no rule change identified. The line itself dates this from 2026-03-20.", "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, "corroboration": [ { "source": "us-ach:src.nacha-fraud-monitoring-phase-1", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms Phase 1, effective March 20, 2026, applies to all ODFIs and to non consumer Originators, Third-Party Service Providers and Third-Party Senders with 2023 origination volume of six million or more, and to RDFIs with 2023 receipt volume of ten million or more, with Phase 2 on June 19, 2026 reaching everyone else." }, { "source": "us-ach:src.nacha-fraud-monitoring-phase-2", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms Phase 2, effective June 19, 2026, eliminates the volume threshold and reaches all remaining non consumer Originators, Third-Party Service Providers, Third-Party Senders and RDFIs." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.participants-only-the-receiving-bank-may-derive-a-return-or-noc", "id": "rule.participants-only-the-receiving-bank-may-derive-a-return-or-noc", "rail": "us-ach", "class": "Rule", "name": "Only the receiving bank may derive a return or a NOC", "statement": "The operator's tool for building a return or a Notification of Change out of an item it already holds is open to the receiving depository institution alone. A processor, a correspondent or any other service provider may not use it for the institution it serves, which the operator puts down to keeping the information private and whole, and the service is aimed at exactly those institutions whose files a processor handles. The institution picks the item and chooses the return reason or change code from a list. A return meant to settle the same day has to be in by 4 p.m. ET, and a paper return by 2:45 p.m. ET; item level detail is not there to work from until the next processing day.", "rests_on": "practice", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-derived-returns-nocs-faq", "section": "the answers on who may process derived returns and NOCs and why, on service providers and correspondents, on the same day and paper cutoffs, and on when item level data becomes available, read 2026-09-20", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.ach-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.operator-derives-dishonors-and-contests", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The Federal Reserve Financial Services FAQ on derived returns and NOCs, read 2026-09-20. This is the operator's own access rule for its tool. It says nothing about whether a processor may build a return in a file of its own and send it in the ordinary way, and this record makes no claim about that. rests_on is practice because it governs an operator service rather than a Nacha obligation.", "confidence": "medium" }, "currency": { "effective_since": "See source edition", "effective_to": null, "effective_note": "The FAQ carries no date, so the read date stands for the edition and no start date is claimed.", "source_edition": "Federal Reserve Financial Services, derived returns and NOCs FAQ, as read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.frb-derived-returns-nocs-faq", "checked_on": "2026-09-20", "checked_by": "validator-us-ach-core-2026-09-20", "notes": "Confirms only RDFIs may process a derived return or NOC (a third party processing a customer's files may not do it on the RDFI's behalf, to protect the privacy and integrity of the information), the return reason code or change code is chosen from a drop-down list, a same-day return must be filed by 4 p.m. ET or 2:45 p.m. ET on paper, and item-level information is not available until the next processing day." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.return-the-operator-stops-a-second-return-it-can-see", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.participants-posting-rests-on-the-account-number", "id": "rule.participants-posting-rests-on-the-account-number", "rail": "us-ach", "class": "Rule", "name": "Posting rests on the account number", "statement": "The receiving bank may decide where an entry posts from the account number alone, and a receiver name that does not match the name on that account is not by itself a reason to refuse it. Checking the name is a choice a receiving bank makes for its own fraud work, not a duty owed to the network, and no receiving bank may turn an entry away because the name was written in a format it did not expect.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-ops-bulletin-2-2024-individual-name", "section": "the bulletin's statement of the posting rule, citing Nacha Operating Rules subsection 3.1.2, read 2026-09-20", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R03", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Nacha's public ACH Operations Bulletin 2-2024, which states the posting rule and cites the Operating Rules subsection it comes from. The Operating Rules themselves were not read.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "The bulletin describes the posting rule as already in force when it was published on 2024-07-22 and gives it no start date, so it is recorded as long-standing.", "source_edition": "Nacha ACH Operations Bulletin 2-2024, dated 2024-07-22, read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-ops-bulletin-2-2024-individual-name", "checked_on": "2026-09-20", "checked_by": "validator-us-ach-core-2026-09-20", "notes": "Confirms the bulletin's own statement that the Nacha Rules permit an RDFI to rely solely on the account number when posting an entry, that the bulletin does not require RDFIs to perform name matching, and that it does not allow an RDFI to return an entry solely because the name is not in the recommended format." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:state.posted", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.participants-receiving-is-an-agreement-too", "id": "rule.participants-receiving-is-an-agreement-too", "rail": "us-ach", "class": "Rule", "name": "Receiving is an agreement too", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraph 12.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:participants by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:participants by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:participants, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.participants-scale-for-context", "id": "rule.participants-scale-for-context", "rail": "us-ach", "class": "Rule", "name": "Scale, for context", "statement": "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.", "rests_on": "guidance", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-ach-volume-statistics", "section": "figures for full year 2025, read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:participants by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:participants by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.nacha-ach-volume-statistics", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms 35.2 billion ACH Network payments in 2025 worth 93 trillion dollars, averaging 141 million payments a day, of which 1.4 billion Same Day ACH payments were worth 3.9 trillion dollars." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.participants-the-entry-condition-is-a-settlement-account", "id": "rule.participants-the-entry-condition-is-a-settlement-account", "rail": "us-ach", "class": "Rule", "name": "The entry condition is a settlement account", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraphs 3.1 and 9.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:participants by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:participants by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:participants, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.participants-the-five-roles", "id": "rule.participants-the-five-roles", "rail": "us-ach", "class": "Rule", "name": "The five roles", "statement": "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.", "rests_on": "guidance", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-how-ach-payments-work", "section": "read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:participants by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:participants by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.nacha-how-ach-payments-work", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:participants, whose check against this source confirmed this detail line." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.participants-the-sanction-for-breaking-the-rules", "id": "rule.participants-the-sanction-for-breaking-the-rules", "rail": "us-ach", "class": "Rule", "name": "The sanction for breaking the rules", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-reversals-and-enforcement", "section": "enforcement rule effective 2021-01-01, read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:participants by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "2021-01-01", "effective_to": null, "effective_note": "Split out of us-ach:participants by the 2026-09 Orca Core migration; no rule change identified. The line itself dates this from 2021-01-01.", "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, "corroboration": [ { "source": "us-ach:src.nacha-reversals-and-enforcement", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms an egregious violation is a willful or reckless action involving at least five hundred entries or an aggregate of at least five hundred thousand dollars, that the Rules Enforcement Panel may classify it as a Class 2 or Class 3 violation, and that a Class 3 violation carries up to five hundred thousand dollars per occurrence and a directive to suspend the Originator or Third-Party Sender." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.participants-there-are-two-operators-not-one", "id": "rule.participants-there-are-two-operators-not-one", "rail": "us-ach", "class": "Rule", "name": "There are two operators, not one", "statement": "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.", "rests_on": "guidance", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-how-ach-payments-work", "section": "read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-same-day-ach-1-million-press-2022-03-18", "section": "which quotes both Federal Reserve Financial Services and The Clearing House on the same rule change", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:participants by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:participants by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.nacha-how-ach-payments-work", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:participants, whose check against this source confirmed this detail line." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.participants-third-party-senders-including-nested-ones", "id": "rule.participants-third-party-senders-including-nested-ones", "rail": "us-ach", "class": "Rule", "name": "Third-Party Senders, including nested ones", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-third-party-sender-roles", "section": "read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:participants by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "2022-09-30", "effective_to": null, "effective_note": "Split out of us-ach:participants by the 2026-09 Orca Core migration; no rule change identified. The line itself dates this from 2022-09-30.", "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, "corroboration": [ { "source": "us-ach:src.nacha-third-party-sender-roles", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the rule, effective September 30, 2022, defines a Nested Third-Party Sender, sets out the chain of agreements, and requires every Third-Party Sender, nested or not, to complete its own Risk Assessment rather than rely on another's." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.tps-nested-chain-of-agreements", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.tps-risk-assessment", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.tps-which-role-an-intermediary-plays", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.participants-what-an-odfi-checks-before-an-originator-starts", "id": "rule.participants-what-an-odfi-checks-before-an-originator-starts", "rail": "us-ach", "class": "Rule", "name": "What an ODFI checks before an originator starts", "statement": "Before a bank lets a business send entries, its supervisor expects it to have underwritten that business much as it would an unsecured loan: confirming the business is real, weighing its financial condition, and checking the financial and sales figures it gave. A written policy behind that says which businesses the bank will take, which it will not, and which it will take only on conditions, what documents it wants, which kinds of entry the customer may send, what collateral it wants, and that the bank may audit how the customer collects authorizations. Where the customer is a third-party sender, the bank is expected to know at the least which originators it is sending for, to get each one's name, taxpayer identification, line of business and location, and to satisfy itself the business is genuine before anything goes out. None of it stops at onboarding: lending and ACH operations are expected to compare notes at least once a year on whether the customer's position has changed, and unauthorized return rates are watched throughout.", "rests_on": "guidance", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "us-ach:src.occ-bulletin-2006-39-ach-risk-management", "section": "the guidance on originator due diligence and underwriting, on the content of an ACH policy, on third-party sender due diligence, and on annual review and return rate monitoring, read 2026-09-20", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:role.third-party-sender", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.limits-the-odfi-sets-an-exposure-limit-on-its-originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "OCC Bulletin 2006-39, read 2026-09-20. This is supervisory guidance to national banks, not a Nacha obligation, which is why rests_on is guidance; a bank supervised by another agency may face a differently worded expectation, and the corpus holds none of those. What a particular ODFI will actually ask of a new originator is that bank's own commercial decision and is not a thing the corpus can state.", "confidence": "medium" }, "currency": { "effective_since": "2006-09-01", "effective_to": null, "effective_note": "The date is the bulletin's own. The OCC page states the guidance remains in effect, with a 2025-03-20 amendment that removed its references to reputation risk.", "source_edition": "OCC Bulletin 2006-39, dated 2006-09-01, as read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.occ-bulletin-2006-39-ach-risk-management", "checked_on": "2026-09-20", "checked_by": "validator-us-ach-core-2026-09-20", "notes": "Confirms underwriting standards should treat a new originator like an unsecured borrower, covering a background check, creditworthiness analysis, sales history review, documentation and permissible SEC codes, exposure limit guidelines, overlimit monitoring, termination procedures and audit rights; that a bank taking on third-party sender traffic should learn each originator's name, taxpayer identification, business line and location and verify the business is genuine; and that lending and ACH operations personnel should consult at least annually on an originator's financial condition while unauthorized return levels are monitored on an ongoing basis." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.participants-who-an-account-holder-asks-about-a-payment", "id": "rule.participants-who-an-account-holder-asks-about-a-payment", "rail": "us-ach", "class": "Rule", "name": "Who an account holder asks about a payment", "statement": "Nacha writes the rules and nothing else: it moves no payment and keeps no record of any individual payment, so it cannot look one up for anybody. A direct deposit that has not arrived is chased with the company or government agency that sent it, because the sender is the party able to find it. A debit the account holder does not recognise goes to the account holder's own bank, and quickly, because the right to disown it does not stay open. A deposit showing as pending usually means the bank has the notice of the payment but not yet the money, and only that bank can say why it is being held.", "rests_on": "guidance", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-consumer-faqs-ach-payments", "section": "the answers on Nacha's own role and access to payment information, on a missing or misdirected direct deposit, on a debit the account holder does not recognise, and on a pending deposit, read 2026-09-20", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.receiver", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R10", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Nacha's public Consumer FAQs on ACH Payments, read 2026-09-20. The page says who to approach; it does not say what the receiving bank may disclose about the account an entry reached, and this record makes no claim about that.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "The page carries no date, and the answers describe standing practice rather than a dated rule change, so this is recorded as long-standing.", "source_edition": "Nacha, Consumer FAQs on ACH Payments, public page as read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-consumer-faqs-ach-payments", "checked_on": "2026-09-20", "checked_by": "validator-us-ach-core-2026-09-20", "notes": "Confirms Nacha does not process payments or hold information about an individual payment; a missing direct deposit is chased with the company or agency that sent it; an unrecognized debit should be reported to the account holder's own bank promptly given the limited time to report unauthorized transactions; and a pending deposit usually means the bank has notice of the payment but not yet the funds, which only that bank can explain." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.participants-who-counts-as-a-bank-for-fedach", "id": "rule.participants-who-counts-as-a-bank-for-fedach", "rail": "us-ach", "class": "Rule", "name": "Who counts as a bank for FedACH", "statement": "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.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraph 2.1(g)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:participants by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:participants by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:participants, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.participants-who-screens-a-domestic-entry-for-sanctions", "id": "rule.participants-who-screens-a-domestic-entry-for-sanctions", "rail": "us-ach", "class": "Rule", "name": "Who screens a domestic entry for sanctions", "statement": "Every party to an ACH entry is bound by the sanctions rules. On a domestic entry the work is split at the two ends: the originating bank has to satisfy itself the originator is not a blocked party and to make a good faith effort that it is not moving blocked funds, and the receiving bank has to satisfy itself the receiver is not a blocked party, so each end is leaning on the other. An originating bank handed a file its customer has already batched is not obliged to break the batch open to look inside. Where it does break it open to pull out the entries that settle on its own books, it is both ends of those entries and answers for them accordingly, and for the rest of what it unbatched, and for what flows through a third-party service provider, it is expected to judge its own exposure and write procedures to match, which may come to screening every record.", "rests_on": "law", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "us-ach:src.ffiec-bsa-aml-ofac-overview", "section": "the Screening ACH transactions passage on domestic entries, batched files, on-us entries and third-party service providers, read 2026-09-20", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R90", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The FFIEC BSA/AML Examination Manual OFAC chapter as posted by OFAC, read 2026-09-20. [Unverified] The chapter's pages carry a 2007 date; it is the OFAC-posted wording and no newer chapter was located for this record, so whether the FFIEC has since restated any of it is an open question.", "confidence": "medium" }, "currency": { "effective_since": "2007-08-24", "effective_to": null, "effective_note": "The date is the one footed on the chapter's pages. The sanctions obligations it describes are older than the chapter; the chapter is the source read.", "source_edition": "FFIEC BSA/AML Examination Manual, OFAC overview, pages footed 8/24/2007, as read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.ffiec-bsa-aml-ofac-overview", "checked_on": "2026-09-20", "checked_by": "validator-us-ach-core-2026-09-20", "notes": "Confirms that on domestic ACH transactions the ODFI must verify the originator is not a blocked party and make a good faith effort that it is not moving blocked funds, the RDFI must verify the receiver is not a blocked party, an ODFI receiving an already-batched file need not unbatch it, an ODFI that unbatches on-us transactions answers for OFAC compliance on those as both ODFI and RDFI, and a bank should assess third-party service provider relationships to set its own risk-based procedures." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.practice-instant-verification-and-micro-deposits", "id": "rule.practice-instant-verification-and-micro-deposits", "rail": "us-ach", "class": "Rule", "name": "Processor practice: instant verification first, micro-deposits as the fallback", "statement": "Processors offer two main ways to verify an account before debiting it. Instant verification has the customer sign in to their bank through a data connection, which confirms the account at once and can also return balance and ownership data (Stripe Financial Connections); Plaid also names a match against account data. Where that is unavailable, the customer keys in the numbers and proves access by reading small deposits back: Stripe sends one $0.01 credit whose description carries a six character code starting SM, or two small credits described ACCTVERIFY, visible in 1 to 2 business days, and allows 10 days and a capped number of tries (ten for a code, three for amounts). Plaid's same day variant sends one $0.01 credit by Same Day ACH, also seen in one to two business days, with a three letter code in the description beside ACCTVERIFY and three tries before the account is locked. Stripe notes that manually entered accounts carry no balance or ownership data.", "rests_on": "practice", "facet": "decision-points", "relations": [ { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.micro-entry", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.stripe-ach-accept-a-payment", "section": "Collect payment method details; Verify bank account with microdeposits; read 2026-09-19", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.stripe-ach-direct-debit", "section": "Verification; read 2026-09-19", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.plaid-same-day-micro-deposits", "section": "Same-Day Micro-deposits overview; read 2026-09-19", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.stripe-nacha-validation-rule-faq", "section": "instant and micro-deposit verification", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.web-validation-methods", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.micro-entries-definition-and-labels", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Processor documentation from Stripe and Plaid, read 2026-09-19. This is one processor's and one data provider's practice, not a rule; other providers differ.", "confidence": "medium" }, "currency": { "effective_since": "Current practice; see source_edition", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from processor documentation; practice changes without notice, so the monthly watch should re-read it.", "source_edition": "Stripe and Plaid public documentation, undated, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.stripe-ach-accept-a-payment", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms Stripe uses Financial Connections by default to instantly verify a bank account with a fallback to manual entry and microdeposit verification, that manually entered accounts lack balance and ownership data, and that the microdeposit fallback sends a single 0.01 USD deposit with a six digit descriptor code starting SM or two ACCTVERIFY deposits, arriving in one to two business days, with a ten day timeout and ten attempts allowed for the code or three for the amounts." }, { "source": "us-ach:src.stripe-ach-direct-debit", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms bank accounts linked through manual entry and microdeposits do not have access to balance, ownership and transaction data, unlike Financial Connections instant verification." }, { "source": "us-ach:src.plaid-same-day-micro-deposits", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms Plaid's Same-Day Micro-deposits sends a single 0.01 USD credit by Same Day ACH that posts in one to two business days, with a three letter verification code in the transaction description alongside ACCTVERIFY, and that a user gets three attempts to enter the code before the linked item is permanently locked." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.prenote-optional-zero-dollar-entry", "id": "rule.prenote-optional-zero-dollar-entry", "rail": "us-ach", "class": "Rule", "name": "Prenotes: an optional zero dollar check of the account details", "statement": "A prenotification is an optional non-value entry an Originator can send before the first live entry so the RDFI can check the account information. It carries a zero amount and the prenote transaction code for the account type and direction: 23 or 28 for a checking credit or debit, 33 or 38 for savings, 53 for a loan credit. The RDFI has to check the routing and account number, not the name on the entry. A problem comes back as a return or a Notification of Change; a prenote the RDFI finds in order draws no reply at all.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.prenote", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nicolet-ach-quick-reference-guide", "section": "Prenotification (Pre-note); Transaction Codes; ACH Returns; read 2026-09-19", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-supplementing-fraud-detection-web-debits", "section": "FAQs: a prenote with no response; read 2026-09-19", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.messages-traffic-that-moves-no-money", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.prenote-wait-before-live-entries", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The Fiscal Service final rule of 2017-09-11 (82 FR 42597) describing the 2014 Nacha change, and bank guides for Originators, read 2026-09-19; the Nacha Operating Rules text was not consulted. Nacha's own 2014 rule page was not found.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from the public sources its sourced_from links name; no rule change identified after the date given.", "source_edition": "Bank guides and Nacha public pages read 2026-09-19; Nacha Operating Rules not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nicolet-ach-quick-reference-guide", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the prenote as an optional zero dollar entry that verifies account information, that the RDFI checks the routing and account number and not the payee name, and the transaction codes for checking, savings and loan credit and debit prenotes." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.format-transaction-codes", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.prenote-response-deadline-and-originator-action", "id": "rule.prenote-response-deadline-and-originator-action", "rail": "us-ach", "class": "Rule", "name": "Prenotes: when a return or NOC counts, and what the Originator must do", "statement": "A return or NOC answering a prenote is timely if the ODFI has it by the opening of business on the second banking day after the prenote's settlement date. After a timely return the Originator must remedy the cause, and after a timely NOC make the correction, before any live entry goes to that account. A NOC for a prenote that arrives after that deadline is corrected within six banking days or before the next entry to the account, whichever is later.", "rests_on": "rule", "facet": "return", "parameters": { "time_window": { "count": 2, "unit": "banking_day", "from": "settlement_date", "text": "by the opening of business on the second banking day after the prenote's settlement date" } }, "relations": [ { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.prenote", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.grand-valley-bank-prenote-waiting-period", "section": "Impact for ODFIs; Impact for Originators", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.treasury-fr-2017-09-11-ach-participation", "section": "2014 Nacha rule book changes, item 9: the no return or NOC condition", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.prenote-wait-before-live-entries", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The Fiscal Service final rule of 2017-09-11 (82 FR 42597) describing the 2014 Nacha change, and bank guides for Originators, read 2026-09-19; the Nacha Operating Rules text was not consulted. Nacha's own 2014 rule page was not found.", "confidence": "medium" }, "currency": { "effective_since": "2014-09-19", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from the public sources its sourced_from links name; no rule change identified after the date given.", "source_edition": "Nacha public rule pages read 2026-09-19; Nacha Operating Rules not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.grand-valley-bank-prenote-waiting-period", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the two banking day timely-return-or-NOC deadline after the prenote's settlement date, that the Originator must remedy a timely return or correct a timely NOC before any live entry, and that an untimely NOC is corrected within six banking days or before the next entry, whichever is later." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.prenote-wait-before-live-entries", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.prenote-wait-before-live-entries", "id": "rule.prenote-wait-before-live-entries", "rail": "us-ach", "class": "Rule", "name": "Prenotes: the wait before the first live entry", "statement": "An Originator that has sent a prenote may send live entries to that account from the third banking day after the prenote's settlement date, as long as its ODFI has received no return or NOC for the prenote. The wait was six banking days until the 2014 rule change, effective 2014-09-19.", "rests_on": "rule", "facet": "hours", "parameters": { "time_window": { "count": 3, "unit": "banking_day", "from": "settlement_date", "text": "live entries from the third banking day after the prenote's settlement date" } }, "relations": [ { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.prenote", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.treasury-fr-2017-09-11-ach-participation", "section": "2014 Nacha rule book changes, item 9", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.grand-valley-bank-prenote-waiting-period", "section": "Impact for Originators; rule date 2014-09-19", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nicolet-ach-quick-reference-guide", "section": "Prenotification (Pre-note)", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.prenote-response-deadline-and-originator-action", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The Fiscal Service final rule of 2017-09-11 (82 FR 42597) describing the 2014 Nacha change, and bank guides for Originators, read 2026-09-19; the Nacha Operating Rules text was not consulted. Nacha's own 2014 rule page was not found.", "confidence": "medium" }, "currency": { "effective_since": "2014-09-19", "effective_to": null, "effective_note": "Drafted on 2026-09-19. The three banking day wait replaced a six banking day wait on 2014-09-19.", "source_edition": "Nacha public rule pages read 2026-09-19; Nacha Operating Rules not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.grand-valley-bank-prenote-waiting-period", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the three banking day wait for live entries after a prenote's settlement, that six banking days was the prior wait, and the 2014-09-19 effective date of the shorter period." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.prenote-optional-zero-dollar-entry", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.prenote-response-deadline-and-originator-action", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.web-validation-prenote-and-micro-entry-results", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.r11-corrected-entry", "id": "rule.r11-corrected-entry", "rail": "us-ach", "class": "Rule", "name": "Corrected entry after an R11 return", "statement": "After an R11 return the Originator may fix the error and send a new entry that matches the authorization. Sent within 60 days of the return, that entry is not treated as a reinitiation.", "rests_on": "rule", "facet": "return", "parameters": { "time_window": { "count": 60, "unit": "calendar_day", "from": "settlement_date", "text": "within 60 days of the R11 return" } }, "relations": [ { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-differentiating-unauthorized-return-reasons", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the retry guidance of us-ach:R11 by the 2026-09 Orca Core migration; the claim is theirs. The sources are those its relations name.", "confidence": "medium" }, "currency": { "effective_since": "2020-04-01", "effective_to": null, "effective_note": "Came with the repurposed R11, effective 2020-04-01, per us-ach:R11.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-differentiating-unauthorized-return-reasons", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-16", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:R11, whose checks against this source confirmed that a corrected entry sent within 60 days of the R11 return is not a reinitiation." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R11", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:rule.recall-a-wrongly-used-reversal-can-be-sent-back", "id": "rule.recall-a-wrongly-used-reversal-can-be-sent-back", "rail": "us-ach", "class": "Rule", "name": "A wrongly used reversal can be sent back", "statement": "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.", "rests_on": "rule", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-reversals-and-enforcement", "section": "reversals rule effective 2021-06-30", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:recall by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "2021-06-30", "effective_to": null, "effective_note": "Split out of us-ach:recall by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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, "corroboration": [ { "source": "us-ach:src.nacha-reversals-and-enforcement", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:recall, whose check against this source confirmed this detail line." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.recall-asking-rather-than-reversing", "id": "rule.recall-asking-rather-than-reversing", "rail": "us-ach", "class": "Rule", "name": "Asking rather than reversing", "statement": "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.", "rests_on": "rule", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "section": "return reason code table for R06, which names Article Two, Subsection 2.12.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "us-ach:exc.request-for-return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.request-for-return-indemnity", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:recall by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. The typed parameters and the links other than sourced_from were added by the migration from the line's own words and are unchecked.", "confidence": "medium" }, "currency": { "effective_since": "2021-06-30", "effective_to": null, "effective_note": "Split out of us-ach:recall by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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, "corroboration": [ { "source": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the R06 return reason code table entry, where the originator must accept a return requested by the ODFI and, if the RDFI agrees to return it, the ODFI must indemnify the RDFI under Article Two, Subsection 2.12.3." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.request-for-return-indemnity", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.sent-to-the-operator", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.recall-before-the-file-leaves-it-is-a-different", "id": "rule.recall-before-the-file-leaves-it-is-a-different", "rail": "us-ach", "class": "Rule", "name": "Before the file leaves, it is a different question", "statement": "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.", "rests_on": "practice", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "us-ach:src.stripe-ach-direct-debit", "section": "read 2026-09-17, cancel and refund sections", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:recall by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:recall by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.stripe-ach-direct-debit", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms Stripe lets a business cancel or capture a pending payment associated with a mandate when a customer revokes it, and treats a refund as a separate credit to the customer's bank account rather than a reversal." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:state.originated", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.recall-how-a-reversal-must-be-formatted", "id": "rule.recall-how-a-reversal-must-be-formatted", "rail": "us-ach", "class": "Rule", "name": "How a reversal must be formatted", "statement": "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.", "rests_on": "rule", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-reversals-and-enforcement", "section": "reversals rule effective 2021-06-30", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.messages-reversal-is-a-field-value-not-a-message-type", "note": "The same formatting rule from the same two sources. That record adds that a reversal is an ordinary entry and that the rail carries no separate cancellation message; this one adds that other fields may change only as far as processing requires.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:recall by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "2021-06-30", "effective_to": null, "effective_note": "Split out of us-ach:recall by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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, "corroboration": [ { "source": "us-ach:src.nacha-reversals-and-enforcement", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the Company ID, SEC code and amount fields of a reversal must be identical to the original entry, other fields may be modified only as necessary for proper processing, and the Company Entry Description field must carry REVERSAL." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.messages-reversal-is-a-field-value-not-a-message-type", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.recall-reversing-a-whole-file", "id": "rule.recall-reversing-a-whole-file", "rail": "us-ach", "class": "Rule", "name": "Reversing a whole file", "statement": "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.", "rests_on": "rule", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "section": "file reversal section", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:recall by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "2021-06-30", "effective_to": null, "effective_note": "Split out of us-ach:recall by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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, "corroboration": [ { "source": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:recall, whose check against this source confirmed this detail line." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.recall-the-operator-has-its-own-cancellation-power", "id": "rule.recall-the-operator-has-its-own-cancellation-power", "rail": "us-ach", "class": "Rule", "name": "The operator has its own cancellation power", "statement": "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.", "rests_on": "rule", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraph 13.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:recall by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:recall by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms paragraph 13.2, that a Reserve Bank may cancel items by initiating a reversing batch under applicable ACH rules if it discovers it sent a duplicate or erroneous batch, will notify the sending bank, and that nothing in the circular waives a Reserve Bank's right of recovery under the law of mistake and restitution." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.recall-the-receiving-side-is-not-obliged-to-fund-it", "id": "rule.recall-the-receiving-side-is-not-obliged-to-fund-it", "rail": "us-ach", "class": "Rule", "name": "The receiving side is not obliged to fund it", "statement": "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.", "rests_on": "rule", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "section": "reversals section", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:recall by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "2021-06-30", "effective_to": null, "effective_note": "Split out of us-ach:recall by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's. Merged 2026-09-20: us-ach:rule.decision-points-whether-to-post-a-reversing-debit stated the same rule from the same source at the same section, that a receiving bank need not post a reversing debit that would overdraw the account or that hits a closed account, and was deleted; the us-ach decision-points fact that listed it now lists this record. This record was kept because it also carries the notice duty and the absence of any need for the receiver to authorise the debit, and because its corroboration records a check of all three of those claims.", "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, "corroboration": [ { "source": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the receiving bank need not post a reversing debit that overdraws the account or hits a closed account, that the receiver must be notified if a reversing entry debits the account, and that the receiver does not need to authorize the reversing debit." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.recall-the-two-clocks-on-a-reversal", "id": "rule.recall-the-two-clocks-on-a-reversal", "rail": "us-ach", "class": "Rule", "name": "The two clocks on a reversal", "statement": "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.", "rests_on": "rule", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "section": "reversals section", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:recall by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "2021-06-30", "effective_to": null, "effective_note": "Split out of us-ach:recall by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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, "corroboration": [ { "source": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:recall, whose check against this source confirmed this detail line." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.hours-a-deadline-stated-in-hours-runs-on-the-clock", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.recall-what-a-reversal-may-be-used-for", "id": "rule.recall-what-a-reversal-may-be-used-for", "rail": "us-ach", "class": "Rule", "name": "What a reversal may be used for", "statement": "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.", "rests_on": "rule", "facet": "recall", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-reversals-and-enforcement", "section": "reversals rule effective 2021-06-30, read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "section": "reversals section", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:recall by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "2021-06-30", "effective_to": null, "effective_note": "Split out of us-ach:recall by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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, "corroboration": [ { "source": "us-ach:src.nacha-reversals-and-enforcement", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:recall, whose check against this source confirmed this detail line." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R62", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.refund-a-business-has-no-equivalent-right", "id": "rule.refund-a-business-has-no-equivalent-right", "rail": "us-ach", "class": "Rule", "name": "A business has no equivalent right", "statement": "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.", "rests_on": "law", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "us-ach:src.reg-e-12-cfr-1005", "section": "1005.2(b)(1), which limits account to one established primarily for personal, family or household purposes, read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "section": "which states that the consumer or corporate entry code determines which return rules apply", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:refund by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:refund by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.reg-e-12-cfr-1005", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:refund, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:state.recredited-under-regulation-e", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.refund-a-merchant-refund-is-a-new-payment", "id": "rule.refund-a-merchant-refund-is-a-new-payment", "rail": "us-ach", "class": "Rule", "name": "A merchant refund is a new payment", "statement": "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.", "rests_on": "practice", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "us-ach:src.stripe-ach-direct-debit", "section": "refunds section, read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:refund by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:refund by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.stripe-ach-direct-debit", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms an ACH Direct Debit refund is always processed as a separate credit to the customer's bank account rather than a reversal, appears as a credit referencing the original payment's statement descriptor, and can be submitted up to 180 days from the original payment." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.refund-federal-payments-have-their-own-recovery-route", "id": "rule.refund-federal-payments-have-their-own-recovery-route", "rail": "us-ach", "class": "Rule", "name": "Federal payments have their own recovery route", "statement": "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.", "rests_on": "guidance", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "us-ach:src.treasury-green-book-2025-03", "section": "Returns and Reclamations chapters", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:refund by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:refund by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.treasury-green-book-2025-03", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms a dedicated Reclamations chapter for recovering payments a federal agency should not have made, and a separate chapter on payments returned in error and obtaining a refund due from the government." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.refund-longer-clocks-for-new-accounts-and-some", "id": "rule.refund-longer-clocks-for-new-accounts-and-some", "rail": "us-ach", "class": "Rule", "name": "Longer clocks for new accounts and some transfers", "statement": "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.", "rests_on": "law", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "us-ach:src.reg-e-12-cfr-1005", "section": "1005.11(c)(3), read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "us-ach:exc.reg-e-error-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:refund by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. The typed parameters and the links other than sourced_from were added by the migration from the line's own words and are unchecked.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:refund by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.reg-e-12-cfr-1005", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:refund, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:state.recredited-under-regulation-e", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.refund-provisional-credit-while-the-bank-investigates", "id": "rule.refund-provisional-credit-while-the-bank-investigates", "rail": "us-ach", "class": "Rule", "name": "Provisional credit while the bank investigates", "statement": "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.", "rests_on": "law", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "us-ach:src.reg-e-12-cfr-1005", "section": "1005.11(c)(2), read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "us-ach:exc.reg-e-error-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:refund by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. The typed parameters and the links other than sourced_from were added by the migration from the line's own words and are unchecked.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:refund by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.reg-e-12-cfr-1005", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:refund, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:state.recredited-under-regulation-e", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.refund-the-ach-tool-that-carries-the-money-back", "id": "rule.refund-the-ach-tool-that-carries-the-money-back", "rail": "us-ach", "class": "Rule", "name": "The ACH tool that carries the money back", "statement": "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.", "rests_on": "rule", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "section": "unauthorised debit section", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-reversals-and-enforcement", "section": "reversals rule effective 2021-06-30, which states the 60 day consumer claim route", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:refund by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "2021-06-30", "effective_to": null, "effective_note": "Split out of us-ach:refund by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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, "corroboration": [ { "source": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms consumer unauthorized debits may be returned within sixty days of posting and that the receiving bank must get a signed Written Statement of Unauthorized Debit before returning the entry." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.refund-the-consumers-statutory-route", "id": "rule.refund-the-consumers-statutory-route", "rail": "us-ach", "class": "Rule", "name": "The consumer's statutory route", "statement": "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.", "rests_on": "law", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "us-ach:src.reg-e-12-cfr-1005", "section": "1005.11(b)(1)(i) and 1005.11(c)(1), read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "part_of", "to": "us-ach:exc.reg-e-error-claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:refund by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. The typed parameters and the links other than sourced_from were added by the migration from the line's own words and are unchecked.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:refund by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.reg-e-12-cfr-1005", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:refund, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:state.recredited-under-regulation-e", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.refund-why-95-days-and-not-60", "id": "rule.refund-why-95-days-and-not-60", "rail": "us-ach", "class": "Rule", "name": "Why 95 days and not 60", "statement": "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.", "rests_on": "rule", "facet": "refund", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-limitation-on-warranty-claims", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.reg-e-12-cfr-1005", "section": "1005.11(b)(1)(i), read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:refund by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "2021-06-30", "effective_to": null, "effective_note": "Split out of us-ach:refund by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's. Merged 2026-09-20: us-ach:rule.consumer-law-where-the-rulebook-meets-the-statute gave the same explanation of the 95 day floor as a statement cycle plus the consumer's 60 days, from the same Nacha source, and was deleted; the us-ach consumer-law fact that listed it now lists this record. This record was kept because it carries two corroborations against two sources where the deleted record carried one, adding Regulation E at 1005.11(b)(1)(i) for the 60 day half of the arithmetic. The deleted record's corroboration recorded a check that the first 95 calendar days from the settlement date of the first unauthorized entry to a consumer account are always covered by the warranty claim cap.", "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, "corroboration": [ { "source": "us-ach:src.reg-e-12-cfr-1005", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:refund, whose check against this source confirmed this detail line." }, { "source": "us-ach:src.nacha-limitation-on-warranty-claims", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:refund, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.refused-noc-window-none-found", "id": "rule.refused-noc-window-none-found", "rail": "us-ach", "class": "Rule", "name": "Refused NOC: no timeframe found", "statement": "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.", "rests_on": "rule", "facet": "messages", "relations": [ { "type": "part_of", "to": "us-ach:exc.refused-notification-of-change", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.treasury-green-book-2025-03", "section": "Notification of Change chapter, section C", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "CBS Bank, Jefferson Bank, Bank of North Dakota and the Treasury Green Book were read on 2026-09-19 for a refusal window; none states one for banks. A 15 day figure appears in a copy of a bank presentation hosted on an unrelated site, which was not used.", "confidence": "low" }, "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": "us-ach:src.treasury-green-book-2025-03", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that changes a federal agency cannot process are usually refused to the financial institution before the next payment is submitted, without stating a fixed deadline for the ODFI to send a refused change." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:exc.refused-notification-of-change", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C61", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C62", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C63", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C64", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C65", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C66", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C67", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C68", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C69", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.reinitiation-after-funds-return", "id": "rule.reinitiation-after-funds-return", "rail": "us-ach", "class": "Rule", "name": "Reinitiation after an insufficient or uncollected funds return", "statement": "After a return for insufficient or uncollected funds the Originator may send the entry again at most twice, three presentments in all, each within 180 days of the original entry's settlement date and marked RETRY PYMT in its company entry description.", "rests_on": "rule", "facet": "return", "parameters": { "time_window": { "count": 180, "unit": "calendar_day", "from": "settlement_date", "text": "within 180 days of the original settlement date" } }, "relations": [ { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the retry guidance of us-ach:R01 and us-ach:R09 by the 2026-09 Orca Core migration; the claim is theirs. No source has been checked for it.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.return-re-presenting-a-failed-debit", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.returned", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R01", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R09", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.request-for-return-indemnity", "id": "rule.request-for-return-indemnity", "rail": "us-ach", "class": "Rule", "name": "ODFI indemnity for a request for return", "statement": "An ODFI that asks an RDFI to return an entry indemnifies the RDFI for honoring the request.", "rests_on": "rule", "facet": "liability", "parameters": { "liability_holder": { "role": "us-ach:role.odfi", "condition": "the RDFI returns the entry at the ODFI's request", "text": "the ODFI" } }, "relations": [ { "type": "part_of", "to": "us-ach:exc.request-for-return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "section": "return reason code table for R06, naming Article Two, Subsection 2.12.3", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.recall-asking-rather-than-reversing", "note": "The same indemnity, stated there as one sentence inside the request for return rule. That record gives the request for return itself, that the receiving bank may refuse, and what R06 records; this one carries the indemnity as a typed liability holder, which is what the R06 code and the liability fact link to.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Carried from us-ach:R06, whose actions and basis state it from Nacha's public Risk Management Topics pages of 2024 and 2025; those pages were not re-read for this record. The detail line of us-ach:liability that restated it was merged into it by the 2026-09 Orca Core migration (slice B), bringing its sources.", "confidence": "low" }, "currency": { "effective_since": "2024-10-01", "effective_to": null, "effective_note": "Came with the expanded request for return, effective 2024-10-01, per us-ach:R06.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the R06 return reason code table entry, that if the RDFI agrees to return the entry the ODFI must indemnify the RDFI according to Article Two, Subsection 2.12.3." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.recall-asking-rather-than-reversing", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R06", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.return-a-new-return-code-with-its-own-window-is-dated", "id": "rule.return-a-new-return-code-with-its-own-window-is-dated", "rail": "us-ach", "class": "Rule", "name": "A new return code with its own window is dated", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-sanctions-compliance-return-code", "section": "effective 2028-03-17, which names Article Three, Section 3.8 and Appendix Four, Part 4.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.return-window-sanctions-determination", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:return by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. The typed parameters and the links other than sourced_from were added by the migration from the line's own words and are unchecked.", "confidence": "medium" }, "currency": { "effective_since": "2028-03-17", "effective_to": null, "effective_note": "Split out of us-ach:return by the 2026-09 Orca Core migration; no rule change identified. The line itself dates this from 2028-03-17.", "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, "corroboration": [ { "source": "us-ach:src.nacha-sanctions-compliance-return-code", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that from March 17, 2028 R90 is added for a sanctions compliance return with its own two banking day timing rule under a new Subsection 3.8.3.6, and R16 reverts to Account Frozen on the same date." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.return-an-adjustment-path-exists-alongside-the-return", "id": "rule.return-an-adjustment-path-exists-alongside-the-return", "rail": "us-ach", "class": "Rule", "name": "An adjustment path exists alongside the return path", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraph 14.4", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:return by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:return by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:return, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.return-disputing-a-return-through-the-operator", "id": "rule.return-disputing-a-return-through-the-operator", "rail": "us-ach", "class": "Rule", "name": "Disputing a return through the operator", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraph 15.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:return by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:return by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:return, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.contested-dishonor-ends-the-network-dispute", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.return-how-a-return-settles", "id": "rule.return-how-a-return-settles", "rail": "us-ach", "class": "Rule", "name": "How a return settles", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraph 14.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.fedach-processing-schedule-2022-09-12", "section": "Electronic Return Items table", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:return by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:return by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing. Merged 2026-09-20: us-ach:rule.settlement-returns-settle-the-same-way stated the same provision of Operating Circular 4, paragraph 14.2, including the same day carve-out, and was deleted; the us-ach settlement fact that listed it now lists this record. This record was kept because it carries the fuller citation, adding the FedACH Processing Schedule's Electronic Return Items table for the settlement times.", "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, "corroboration": [ { "source": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:return, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.same-day-returns-regardless-of-forward", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.returned", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.return-re-presenting-a-failed-debit", "id": "rule.return-re-presenting-a-failed-debit", "rail": "us-ach", "class": "Rule", "name": "Re-presenting a failed debit", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "section": "re-initiation section", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.stripe-ach-direct-debit", "section": "read 2026-09-17, which caps its own automatic retries at 2 within 40 days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.reinitiation-after-funds-return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.no-reinitiation-without-new-authorization", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:return by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. The typed parameters and the links other than sourced_from were added by the migration from the line's own words and are unchecked.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:return by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.return-returns-can-be-sent-back-again", "id": "rule.return-returns-can-be-sent-back-again", "rail": "us-ach", "class": "Rule", "name": "Returns can be sent back again", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "us-ach:src.treasury-green-book-2025-03", "section": "Returns chapter section D", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "section": "note that an untimely return may be dishonoured without permission", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:return by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:return by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.treasury-green-book-2025-03", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms a government disbursing office dishonors a return of a federal payment where any of four fields, the trace number, effective entry date, amount and individual ID number, differ from the original payment." }, { "source": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the R31 permissible return entry note, that if the Originator or ODFI has not given permission for an untimely return, the return may be dishonored." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:exc.dishonored-return", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.return-dishonored", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.returned", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R69", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.return-the-mechanism", "id": "rule.return-the-mechanism", "rail": "us-ach", "class": "Rule", "name": "The mechanism", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraph 14.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:return by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:return by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:return, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:state.returned", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.return-the-operator-stops-a-second-return-it-can-see", "id": "rule.return-the-operator-stops-a-second-return-it-can-see", "rail": "us-ach", "class": "Rule", "name": "The operator stops a second return it can see", "statement": "The operator's derive tool will not build a second return on an entry it already returned through that same tool on the current processing day or in the ten business days before it. The guard reaches only what the tool itself did: where the first return went out in a file the institution put together and sent in, the tool cannot see it and will let the entry be returned again. So the protection against returning one entry twice is real but partial, and an institution that returns through both routes has to keep its own count.", "rests_on": "practice", "facet": "return", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-derived-returns-nocs-faq", "section": "the answer on whether an entry already returned can be derived again, naming the current day and previous ten business days and the case of a return sent in a customer initiated input file, read 2026-09-20", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.ach-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.participants-only-the-receiving-bank-may-derive-a-return-or-noc", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "The Federal Reserve Financial Services FAQ on derived returns and NOCs, read 2026-09-20. The FAQ does not say what happens to a duplicate return that does get through, and this record makes no claim about that. rests_on is practice because it describes an operator service, not a Nacha obligation.", "confidence": "medium" }, "currency": { "effective_since": "See source edition", "effective_to": null, "effective_note": "The FAQ carries no date, so the read date stands for the edition and no start date is claimed.", "source_edition": "Federal Reserve Financial Services, derived returns and NOCs FAQ, as read 2026-09-20", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.frb-derived-returns-nocs-faq", "checked_on": "2026-09-20", "checked_by": "validator-us-ach-core-2026-09-20", "notes": "Confirms the Derive a Return or NOC function blocks returning the same forward item again if it was already returned through that function during the current day or the prior 10 business days, but does not know about a return already sent through a customer-initiated input file and will let that item be derived again." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.return-what-a-blocked-debit-comes-back-as", "id": "rule.return-what-a-blocked-debit-comes-back-as", "rail": "us-ach", "class": "Rule", "name": "What a blocked debit comes back as", "statement": "A debit that meets a block or misses a filter is returned to the originator, and on a business account the code it usually carries is R29, the receiver having told its bank this originator may not debit it. There is no code reserved for a block, so what arrives depends on the receiving bank rather than on a rule. Retrying is pointless while the instruction stands: the fix is for the receiver to add the originator to the list its bank keeps, using the originating company identification, and only then to present again.", "rests_on": "practice", "facet": "return", "relations": [ { "type": "sourced_from", "to": "us-ach:src.slash-ach-blocks-and-filters-2026-05-26", "section": "the passage naming R29 as the return a debit hitting a block or filter rejection typically draws, and the passage on the fields a filter matches, read 2026-09-20", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.androscoggin-ach-block-filter-appendix-2021-07", "section": "sections 3.1 and 4.3, that a blocked entry and an undecided exception entry are returned to the originator, read 2026-09-20", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R29", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.decision-points-blocking-or-filtering-incoming-debits", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "One bank's published block and filter contract for the fact that the entry is returned, and a vendor explainer for the code. [Unverified] Only the vendor explainer names R29, and no bank, operator or Nacha page read for this record ties a debit block to a particular return code; R29 is what the corpus's own R29 record describes for a non-consumer receiver telling its bank an originator is not authorised, which fits, but the corpus does not claim the rules require it. What a consumer account's block produces was not established at all. rests_on is practice for the same reason.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Neither source dates the practice, so it is recorded as long-standing.", "source_edition": "Slash explainer dated 2026-05-26; Androscoggin Bank ACH Block and Filter Service Appendix, form AB 711 revision 7/2021; both read 2026-09-20", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.return-what-a-processor-calls-a-late-return", "id": "rule.return-what-a-processor-calls-a-late-return", "rail": "us-ach", "class": "Rule", "name": "What a processor calls a late return", "statement": "Processors use late return for a debit that is successfully disputed after the ordinary windows have closed, sixty calendar days on a consumer account and two business days on a business one. It is rare, it is settled between the banks rather than through anything the originator can contest, and it is the reason a payment can come undone long after it looked finished. The other term worth separating from it is the delay before any outcome is known at all: a debit takes up to four business days to report success or failure, and where a failure lands after the payment was already treated as complete a processor may book it as a dispute, with insufficient funds, incorrect account details or the bank being unable to process as the reason given. That is late in the sense of arriving after the money was counted, not late against the network's window, and it is not the same thing as a late return.", "rests_on": "practice", "facet": "return", "relations": [ { "type": "sourced_from", "to": "us-ach:src.stripe-ach-direct-debit", "section": "the disputes section on the sixty calendar day and two business day windows and on what a late return is, and the transaction failures section on the up to four business day notification and on a failure arriving after the payment succeeded, read 2026-09-20", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.return-window-2-banking-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.return-window-60-calendar-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Stripe's public ACH Direct Debit documentation, read 2026-09-20. Late return is a processor's word, not a term the Nacha rules define, which is why rests_on is practice; the network's own name for a return sent after its window is a late return the ODFI may dishonor, which the corpus holds separately. [Unverified] No source read here says whether returning early or late inside the ordinary window changes anything, and the corpus still does not answer that.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "The documentation is undated and describes standing behaviour, so this is recorded as long-standing against the read of 2026-09-20.", "source_edition": "Stripe documentation, ACH Direct Debit payments, public documentation as read 2026-09-20", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.return-what-the-consumer-has-to-sign", "id": "rule.return-what-the-consumer-has-to-sign", "rail": "us-ach", "class": "Rule", "name": "What the consumer has to sign", "statement": "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.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "sourced_from", "to": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "section": "section on unauthorised debits", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.written-statement-of-unauthorized-debit", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:return by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. The typed parameters and the links other than sourced_from were added by the migration from the line's own words and are unchecked.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:return by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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, "corroboration": [ { "source": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the receiving bank must get a signed Written Statement of Unauthorized Debit from the account holder when a debit is disputed as unauthorized, and that the originator may obtain a copy of that statement through its own bank." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.written-statement-of-unauthorized-debit", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.return-window-2-banking-days", "id": "rule.return-window-2-banking-days", "rail": "us-ach", "class": "Rule", "name": "Return window: 2 banking days", "statement": "For the return reasons linked to it, the RDFI has 2 banking days after the settlement date of the original entry to return it.", "rests_on": "rule", "facet": "return", "parameters": { "time_window": { "count": 2, "unit": "banking_day", "from": "settlement_date", "text": "2 banking days" } }, "relations": [ { "type": "part_of", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.fhb-ach-return-reason-codes", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.modern-treasury-ach-return-code-reference", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.bmo-ach-return-reason-codes-2025-05", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-reversals-and-enforcement", "section": "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", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "section": "return reason code table, which gives the 2 banking day window as the general rule", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the return windows of us-ach:R01, us-ach:R02, us-ach:R03, us-ach:R04, us-ach:R08, us-ach:R09, us-ach:R12, us-ach:R14, us-ach:R15, us-ach:R16, us-ach:R17, us-ach:R20, us-ach:R21, us-ach:R22, us-ach:R24, us-ach:R29, us-ach:R39 and us-ach:R50 by the 2026-09 Orca Core migration; the claim is theirs. The sources are those its relations name. The detail line of us-ach:return that restated it was merged into it by the 2026-09 Orca Core migration (slice B), bringing its sources.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.fhb-ach-return-reason-codes", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:R01, us-ach:R02, us-ach:R03, us-ach:R04, us-ach:R08, us-ach:R09, us-ach:R12, us-ach:R16, us-ach:R20, us-ach:R21, us-ach:R22, us-ach:R24 and us-ach:R29, whose checks against this source confirmed the 2 banking day return window." }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:R01, us-ach:R02, us-ach:R03, us-ach:R04, us-ach:R08, us-ach:R09, us-ach:R12, us-ach:R16, us-ach:R17, us-ach:R20, us-ach:R21, us-ach:R22, us-ach:R24, us-ach:R29, us-ach:R39 and us-ach:R50, whose checks against this source confirmed the 2 banking day return window." }, { "source": "us-ach:src.modern-treasury-ach-return-code-reference", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:R14 and us-ach:R15, whose checks against this source confirmed the 2 banking day return window." }, { "source": "us-ach:src.bmo-ach-return-reason-codes-2025-05", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:R17, whose checks against this source confirmed the 2 banking day return window." }, { "source": "us-ach:src.nacha-reversals-and-enforcement", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:return, whose check against this source confirmed the detail line that restated this Rule." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.hours-a-bank-closed-on-the-settlement-date", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-return-timeframes", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.return-what-a-processor-calls-a-late-return", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.returned", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R01", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R02", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R03", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R04", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R08", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R09", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R12", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R14", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R15", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R16", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R17", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R20", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R21", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R22", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R24", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R29", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R39", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R50", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R80", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R81", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R82", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R83", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R84", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R85", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.return-window-60-calendar-days", "id": "rule.return-window-60-calendar-days", "rail": "us-ach", "class": "Rule", "name": "Extended return window: 60 calendar days", "statement": "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.", "rests_on": "rule", "facet": "return", "parameters": { "time_window": { "count": 60, "unit": "calendar_day", "from": "settlement_date", "text": "60 calendar days" } }, "relations": [ { "type": "part_of", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.fhb-ach-return-reason-codes", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-differentiating-unauthorized-return-reasons", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.bmo-ach-return-reason-codes-2025-05", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-reversals-and-enforcement", "section": "reversals rule effective 2021-06-30, the R11 60 day window as the consumer claim route", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "section": "return reason code table entries for R05 and R07 and their neighbours", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the return windows of us-ach:R05, us-ach:R07, us-ach:R10, us-ach:R11, us-ach:R33, us-ach:R37, us-ach:R38, us-ach:R51, us-ach:R52 and us-ach:R53 by the 2026-09 Orca Core migration; the claim is theirs. The sources are those its relations name. The detail line of us-ach:return that restated it was merged into it by the 2026-09 Orca Core migration (slice B), bringing its sources.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.fhb-ach-return-reason-codes", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:R05 and us-ach:R07, whose checks against this source confirmed the 60 calendar day return window." }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:R05, us-ach:R07, us-ach:R33, us-ach:R37, us-ach:R38, us-ach:R51, us-ach:R52 and us-ach:R53, whose checks against this source confirmed the 60 calendar day return window." }, { "source": "us-ach:src.nacha-differentiating-unauthorized-return-reasons", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-16", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:R10 and us-ach:R11, whose checks against this source confirmed the 60 calendar day return window." }, { "source": "us-ach:src.bmo-ach-return-reason-codes-2025-05", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:R33, us-ach:R37 and us-ach:R38, whose checks against this source confirmed the 60 calendar day return window." }, { "source": "us-ach:src.nacha-reversals-and-enforcement", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:return, whose check against this source confirmed the detail line that restated this Rule." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.iat-return-timeframes", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.return-what-a-processor-calls-a-late-return", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.returned", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R05", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R07", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R10", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R11", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R33", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R37", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R38", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R51", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R52", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R53", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:rule.return-window-enr-agency", "id": "rule.return-window-enr-agency", "rail": "us-ach", "class": "Rule", "name": "Federal agency return of an ENR entry: no timeframe found", "statement": "No return timeframe stated in the public sources consulted", "rests_on": "rule", "facet": "return", "relations": [ { "type": "part_of", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.federal-government-agency", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the return windows of us-ach:R40, us-ach:R41, us-ach:R42, us-ach:R43, us-ach:R44, us-ach:R45, us-ach:R46 and us-ach:R47 by the 2026-09 Orca Core migration; the claim is theirs. No source has been checked for it.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.format-enr-entry-codes", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R40", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R41", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R42", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R43", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R44", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R45", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R46", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R47", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.return-window-late-by-agreement", "id": "rule.return-window-late-by-agreement", "rail": "us-ach", "class": "Rule", "name": "Late return with the ODFI's agreement: window set by agreement", "statement": "Not defined; set by agreement between ODFI and RDFI", "rests_on": "rule", "facet": "return", "relations": [ { "type": "part_of", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.fhb-ach-return-reason-codes", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the return windows of us-ach:R31 by the 2026-09 Orca Core migration; the claim is theirs. The sources are those its relations name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.fhb-ach-return-reason-codes", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:R31, whose checks against this source confirmed that the window is negotiated between ODFI and RDFI and the RDFI takes the return." }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:R31, whose checks against this source confirmed that the window is negotiated between ODFI and RDFI and the RDFI takes the return." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R31", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:rule.return-window-next-file-delivery", "id": "rule.return-window-next-file-delivery", "rail": "us-ach", "class": "Rule", "name": "ACH Operator return: next file delivery after processing", "statement": "Next file delivery time following processing", "rests_on": "rule", "facet": "return", "relations": [ { "type": "part_of", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.ach-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the return windows of us-ach:R30, us-ach:R32 and us-ach:R34 by the 2026-09 Orca Core migration; the claim is theirs. No source has been checked for it.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.commerce-bank-ach-return-noc-tran-codes-2022-11", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the return deadline listed for R13, R26, R28, R30, R32 and R34 is the next file delivery time following processing." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R30", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R32", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R34", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.return-window-odfi-request", "id": "rule.return-window-odfi-request", "rail": "us-ach", "class": "Rule", "name": "Return at the ODFI's request: no fixed window", "statement": "Not defined; RDFI compliance is optional and no fixed deadline applies", "rests_on": "rule", "facet": "return", "relations": [ { "type": "part_of", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.fhb-ach-return-reason-codes", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the return windows of us-ach:R06 by the 2026-09 Orca Core migration; the claim is theirs. The sources are those its relations name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.fhb-ach-return-reason-codes", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:R06, whose checks against this source confirmed that the window is undefined and set by the ODFI's request, and that the RDFI takes the return." }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:R06, whose checks against this source confirmed that the window is undefined and set by the ODFI's request, and that the RDFI takes the return." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R06", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:rule.return-window-operator-reject", "id": "rule.return-window-operator-reject", "rail": "us-ach", "class": "Rule", "name": "ACH Operator reject: returned at processing", "statement": "At processing, when the entry is rejected", "rests_on": "rule", "facet": "return", "relations": [ { "type": "part_of", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.ach-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.bmo-ach-return-reason-codes-2025-05", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the return windows of us-ach:R13, us-ach:R18, us-ach:R19, us-ach:R25, us-ach:R26, us-ach:R27, us-ach:R28, us-ach:R35 and us-ach:R36 by the 2026-09 Orca Core migration; the claim is theirs. The sources are those its relations name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.bmo-ach-return-reason-codes-2025-05", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:R13, us-ach:R26 and us-ach:R28, whose checks against this source confirmed that the code is an ACH Operator reject with no separate RDFI deadline." }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:R18, us-ach:R19, us-ach:R25, us-ach:R27 and us-ach:R35, whose checks against this source confirmed that the code is an ACH Operator reject with no separate RDFI deadline." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.format-mandatory-required-optional-fields", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.returned", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R13", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R18", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R19", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R25", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R26", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R27", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R28", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R35", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R36", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.return-window-refused-credit", "id": "rule.return-window-refused-credit", "rail": "us-ach", "class": "Rule", "name": "Return window for a refused credit: 2 banking days from the refusal", "statement": "When the Receiver refuses a credit, the RDFI has 2 banking days from receiving that refusal to return the entry.", "rests_on": "rule", "facet": "return", "parameters": { "time_window": { "count": 2, "unit": "banking_day", "from": "notice_of_refusal", "text": "2 banking days after the RDFI receives the Receiver's notice of refusal" } }, "relations": [ { "type": "part_of", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the return windows of us-ach:R23 by the 2026-09 Orca Core migration; the claim is theirs. No source has been checked for it.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms an RDFI must transmit an R23 credit entry decline return so it is available to the ODFI no later than the opening of business on the second banking day following the RDFI's receipt of the receiver's notice of refusal." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R23", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.return-window-sanctions-determination", "id": "rule.return-window-sanctions-determination", "rail": "us-ach", "class": "Rule", "name": "Return window for a sanctions compliance return: 2 banking days from the determination", "statement": "For a return made because of the RDFI's sanctions compliance obligations, the RDFI or Gateway has 2 banking days from the RDFI's determination to return the entry.", "rests_on": "rule", "facet": "return", "parameters": { "time_window": { "count": 2, "unit": "banking_day", "from": "determination", "text": "2 banking days from the RDFI's sanctions compliance determination" } }, "relations": [ { "type": "part_of", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.gateway", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-sanctions-compliance-return-code", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the return windows of us-ach:R90 by the 2026-09 Orca Core migration; the claim is theirs. The sources are those its relations name.", "confidence": "medium" }, "currency": { "effective_since": "2028-03-17", "effective_to": null, "effective_note": "Approved 2025-10-14 with R90; in force 2028-03-17, per us-ach:R90.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-sanctions-compliance-return-code", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-17c", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:R90, whose checks against this source confirmed the 2 banking day window measured from the RDFI's sanctions determination, and that the RDFI or Gateway takes the return." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.iat-ofac-hold-before-posting", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.return-a-new-return-code-with-its-own-window-is-dated", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R90", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:rule.same-day-entry-fee", "id": "rule.same-day-entry-fee", "rail": "us-ach", "class": "Rule", "name": "Same Day Entry Fee: who pays, who receives, what is exempt", "statement": "For every forward entry that is processed and settled same day, the ODFI pays a Same Day Entry Fee that is credited to the RDFI to cover its cost of supporting Same Day ACH; the fee is $0.052 per entry in the 2026 FedACH schedule. The ACH Operators collect it for the RDFIs and settle it monthly, and neither the operators nor Nacha keep any of it. The Federal Reserve Banks settle the fee on every inter-operator entry and on entries where both banks use FedACH; The Clearing House settles only entries where both banks are its customers. Government forward entries pay it like commercial ones, and so do prenotifications and reversals settled same day. Returns and NOCs never pay it, whether or not they settle same day, and neither does a forward entry that ends up settling next day or one the operator itself returns before it reaches the RDFI. Nacha's volume review in 2026 left the amount unchanged until a ten year review.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-same-day-ach-faq", "section": "Government Participation and Same Day Entry Fee and Accounting answers; Returns, NOCs, Prenotifications and Reversals answers; Overall Edits and Reject Process", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-same-day-ach-phase-1", "section": "Technical: new Section 1.12 and Appendix Eleven; FAQs: the fee, NOCs, returns, operator returned entries and reversals", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-fedach-fee-schedule-2026", "section": "Fees and Credits Established by Nacha table, billing codes 57610 and 57611, with footnote 26", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-same-day-fee-no-change-2026-05-07", "section": "whole notice", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.ach-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.noc-same-day-and-fee", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.same-day-fedach-operator-charges", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "2016-09-23", "effective_to": null, "effective_note": "The fee exists since the Same Day ACH rule effective 2016-09-23; the $0.052 amount is as listed in the 2026 FedACH fee schedule, and Nacha's notice of 2026-05-07 keeps it unchanged for two years.", "source_edition": "Federal Reserve Same Day ACH FAQ (updated 2022-03-23) and 2026 FedACH fee schedule; Nacha public pages, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.frb-same-day-ach-faq", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the Same Day Entry Fee is assessed to the ODFI and credited to the RDFI to cover its costs of supporting Same Day ACH, collected by the ACH operators on the RDFIs' behalf and settled monthly with no portion kept by the operators or Nacha; the Federal Reserve Banks settle it on inter-operator and FedACH intra-operator entries while The Clearing House settles only its own intra-operator entries; government entries, prenotifications and reversals pay it when they settle same day, while returns and NOCs never do. The FedACH fee schedule confirms the amount as 0.052 dollars per item in 2026, and Nacha's own review confirms the fee stayed unchanged pending a ten year review." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.same-day-fedach-operator-charges", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.same-day-government-entries", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.same-day-ineligible-entry-settles-next-day", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.same-day-fedach-operator-charges", "id": "rule.same-day-fedach-operator-charges", "rail": "us-ach", "class": "Rule", "name": "FedACH's own same day charges, separate from the Nacha fee", "statement": "Apart from the Nacha Same Day Entry Fee that passes to the RDFI, FedACH bills an ODFI its own charges for same day origination in 2026: a surcharge of $0.0010 on each forward item that qualifies for same day processing and settlement, added to the ordinary origination fee, and $10.00 a month for each routing number that originates at least one such item in the month.", "rests_on": "practice", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-fedach-fee-schedule-2026", "section": "Origination table, SameDay Service forward item with footnote 5; Other Fees and Discounts, SameDay Service Origination Participation Fee with footnote 22", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.ach-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.same-day-entry-fee", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted. The Clearing House's charges for the same service were not looked for.", "confidence": "medium" }, "currency": { "effective_since": "2026-01-01", "effective_to": null, "effective_note": "Amounts as listed in the FedACH 2026 fee schedule [Unverified: effective from 2026-01-01]; the operator sets them each year.", "source_edition": "FedACH Services 2026 Fee Schedule, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.frb-fedach-fee-schedule-2026", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the 2026 FedACH schedule lists a SameDay Service forward item surcharge of 0.0010 dollars per item, in addition to the ordinary per item origination fee, and a SameDay Service Origination Participation Fee of 10.00 dollars per routing number per month, separate from the Nacha Same Day Entry Fee shown elsewhere on the same schedule." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.same-day-entry-fee", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.same-day-government-entries", "id": "rule.same-day-government-entries", "rail": "us-ach", "class": "Rule", "name": "Government entries in Same Day ACH", "statement": "Federal government entries take part in Same Day ACH on the same terms as others: after Treasury's final rule under 31 CFR Part 210, Treasury can originate and receive payments up to $1,000,000 in any of the three windows, and the ODFI pays the Same Day Entry Fee on a government forward item that settles same day. Returns where the ODFI or RDFI is a federal government routing number settle same day if they are not future dated and reach FedACH within a current day window. Entries to and from state government agencies may also be sent same day.", "rests_on": "guidance", "facet": "limits", "parameters": { "limit": { "amount": 1000000, "currency": "USD", "per": "entry", "text": "Treasury payments up to $1,000,000 in any same day window" } }, "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-same-day-ach-faq", "section": "Government Participation answers", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.federal-government-agency", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.limits-the-same-day-ach-ceiling-today", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.same-day-entry-fee", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.same-day-returns-regardless-of-forward", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted. The Treasury final rule itself was not opened; the record relies on the Federal Reserve's account of it. Whether Treasury follows the $10,000,000 ceiling due on 2027-09-17 was not found [Unverified].", "confidence": "medium" }, "currency": { "effective_since": "2022-03-18", "effective_to": null, "effective_note": "The $1,000,000 figure for Treasury follows the Nacha ceiling in force since 2022-03-18, per the Federal Reserve FAQ updated 2022-03-23.", "source_edition": "Federal Reserve Same Day ACH FAQ (updated 2022-03-23), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.frb-same-day-ach-faq", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms Treasury's final rule under 31 CFR Part 210 supports the 1,000,000 dollar Same Day ACH limit and lets Treasury originate and receive payments up to that amount in any processing window, that the ODFI is assessed the Same Day Entry Fee on a government forward item settled same day, that returns with a federal government routing number as ODFI or RDFI are eligible for same day settlement when not future dated and received within a current day window, and that state government agencies may also originate and receive same day entries." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.same-day-ineligible-entry-settles-next-day", "id": "rule.same-day-ineligible-entry-settles-next-day", "rail": "us-ach", "class": "Rule", "name": "An entry that misses any same day condition still clears, one day later", "statement": "FedACH gives a forward entry same day settlement only when all of four tests pass. Timing: the file reached FedACH by a same day deadline, and the batch header's effective entry date is today, stale or invalid rather than a future date. Content: the amount is within the per entry ceiling ($2,500 for RCK and XCK), and the SEC code is neither IAT nor ENR. An entry that fails any one of them is still processed but settles on the next business day, with no Same Day Entry Fee. The test is per entry: in a batch sent for same day, an entry above the ceiling gets the next business day's settlement date while the rest of the batch settles same day. The operators neither edit nor rely on the optional same day indicator an Originator may put in the company descriptive date, and same day did not change how they reject batches or files.", "rests_on": "guidance", "facet": "limits", "parameters": { "limit": { "amount": 2500, "currency": "USD", "per": "entry", "text": "$2,500 per entry for RCK and XCK" }, "eligibility": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [ "us-ach:txn.iat", "us-ach:txn.enr" ], "text": "forward entries other than IAT and ENR, within the ceiling, received by a same day deadline, not future dated" } }, "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-same-day-ach-faq", "section": "Value Limit answers; Overall Edits and Reject Process", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-expanding-same-day-ach", "section": "FAQs: eligibility in the third window and the optional SD1800 indicator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.ach-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.rck", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.xck", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.limits-eligibility-limits-not-just-dollar-limits", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.limits-the-same-day-ach-ceiling-today", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.same-day-entry-fee", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted. The Federal Reserve FAQ states the ceiling as $1,000,000; the $10,000,000 ceiling due on 2027-09-17 is a separate Rule, and whether the $2,500 RCK and XCK figure changes with it was not found [Unverified].", "confidence": "medium" }, "currency": { "effective_since": "2016-09-23", "effective_to": null, "effective_note": "Per entry treatment as described in the Federal Reserve FAQ updated 2022-03-23; the ceiling it names has changed over time and is held in its own Rules.", "source_edition": "Federal Reserve Same Day ACH FAQ (updated 2022-03-23), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.frb-same-day-ach-faq", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the four same day conditions (not IAT or ENR, not over the 1,000,000 dollar or 2,500 dollar RCK/XCK ceiling, received by the same day deadline, and effective entry date not future dated), that failing any one condition still processes the entry but settles it next business day with no fee, that the test applies per entry within a batch, and that the operators neither edit nor rely on the optional same day indicator in the company descriptive date field." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:state.awaiting-settlement", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.same-day-no-deadline-extensions", "id": "rule.same-day-no-deadline-extensions", "rail": "us-ach", "class": "Rule", "name": "No extensions of Same Day ACH deadlines", "statement": "FedACH does not grant an ODFI extra time past a Same Day ACH processing deadline. A file that misses a window goes to the next one, or to next day settlement after the last.", "rests_on": "guidance", "facet": "hours", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-same-day-ach-faq", "section": "Same Day ACH Transaction Transmission and Settlement: the answer on deadline extensions", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.ach-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.hours-same-day-transmission-deadlines", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.hours-release-not-transmission-is-what-counts", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted. The Clearing House's practice was not looked for.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "As published by the Federal Reserve in its FAQ updated 2022-03-23; no effective date given.", "source_edition": "Federal Reserve Same Day ACH FAQ (updated 2022-03-23), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.frb-same-day-ach-faq", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms FedACH will not allow an ODFI an extension on a Same Day ACH deadline." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:state.originated", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.same-day-return-not-before-forward", "id": "rule.same-day-return-not-before-forward", "rail": "us-ach", "class": "Rule", "name": "A return must not settle before its forward entry, and FedACH does not check", "statement": "Under the Nacha rules a return must not settle earlier than the forward entry it returns. FedACH does not verify this. It relies on the RDFI building the return from the forward entry's batch header, so the return carries the same effective entry date and, built that way, cannot settle before the original.", "rests_on": "guidance", "facet": "return", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-same-day-ach-faq", "section": "Overall Edits and Reject Process: the answer on returns settling before the forward entry", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.ach-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.same-day-returns-regardless-of-forward", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted. The Nacha rule is known here only as the Federal Reserve reports it.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "As published by the Federal Reserve in its FAQ updated 2022-03-23; no effective date given.", "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": "us-ach:src.frb-same-day-ach-faq", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the ACH Rules require a return to not settle before its forward entry, that FedACH does not verify this, and that FedACH relies on the return being built from the forward entry's batch header so both carry the same effective entry date, meaning a correctly built return cannot settle before the original." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.same-day-returns-regardless-of-forward", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.same-day-returns-regardless-of-forward", "id": "rule.same-day-returns-regardless-of-forward", "rail": "us-ach", "class": "Rule", "name": "Returns can settle same day whatever the forward entry did", "statement": "Every electronic return that reaches FedACH by the last same day deadline, 16:45 Eastern, is eligible for same day settlement, credit or debit, any SEC code, any amount, commercial or government, even when the entry it returns settled next day; the per entry ceiling and the IAT exclusion apply only to forward entries. The effective entry date decides: a future dated return never settles same day, while one with a current, stale or invalid date received by 16:45 Eastern settles that day. Paper returns received by 08:00 Eastern also settle that day. FedACH's derived returns function on FedLine Web cannot return a same day forward entry on the day it settled, because item detail is not available until the next processing day; an RDFI wanting that must send its own return file by 16:45 Eastern.", "rests_on": "guidance", "facet": "return", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-same-day-ach-faq", "section": "Returns, NOCs, Prenotifications and Reversals answers; the answer on return deadlines under Same Day ACH", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-expanding-same-day-ach", "section": "FAQs: returns and NOCs in the third window, the former returns only window", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-same-day-ach-phase-1", "section": "FAQs: returns", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.ach-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "part_of", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.return-how-a-return-settles", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.hours-return-deadlines-follow-the-same-clock", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.same-day-return-not-before-forward", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.noc-same-day-and-fee", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "2016-09-23", "effective_to": null, "effective_note": "Returns became eligible for same day processing with the first Same Day ACH phase; the 16:45 Eastern deadline dates from the third window, 2021-03-19, which absorbed the operators' former returns only window.", "source_edition": "Federal Reserve Same Day ACH FAQ (updated 2022-03-23); Nacha public rule pages, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.frb-same-day-ach-faq", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms all electronic returns received before the 4:45pm ET deadline, any SEC code, amount, credit or debit, commercial or government, are eligible for same day settlement regardless of whether the forward entry settled same day; a future dated return never settles same day while a current, stale or invalid dated return received by that deadline does; paper returns received by the 8:00am ET deadline also settle that day; and FedLine Web's derived returns function cannot return a same day forward entry on the day it settled because item level detail is not available until the next processing day." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.same-day-government-entries", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.same-day-return-not-before-forward", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.same-day-risk-pended-batches", "id": "rule.same-day-risk-pended-batches", "rail": "us-ach", "class": "Rule", "name": "Batches pended by FedACH origination monitoring", "statement": "An ODFI using the FedACH Risk Origination Monitoring Service can set dollar thresholds by routing number or company ID; a batch over a threshold is held for review. To keep same day settlement the ODFI must release the held batch by 16:45 Eastern, by hand or through the service's Same Day Auto-Release feature. A batch released after 16:45 Eastern settles next day even if its entries were otherwise eligible. A batch never released by the end of the day takes the ODFI's chosen end of day default at the 02:15 Eastern deadline, and if that default is to release, eligible entries settle at 08:30 Eastern on the next business day. The Federal Reserve suggests sending files needing monitoring before 16:30 Eastern so the checks finish in time.", "rests_on": "guidance", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-same-day-ach-faq", "section": "Value-Added Services: the FedACH Risk Origination Monitoring Service answer", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.ach-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.hours-release-not-transmission-is-what-counts", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.settlement-future-dated-settlement-clock-time", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted. The service is optional and FedACH specific.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "As published by the Federal Reserve in its FAQ updated 2022-03-23; no effective date given.", "source_edition": "Federal Reserve Same Day ACH FAQ (updated 2022-03-23), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.frb-same-day-ach-faq", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms an ODFI using the FedACH Risk Origination Monitoring Service must release a pended batch by 4:45pm ET, by hand or through Same Day Auto-Release, to keep same day settlement; a batch released after that deadline settles next day even if otherwise eligible; a batch never released takes the end of day default at the 2:15am ET deadline, settling at 8:30am ET the next business day if that default is to release; and the Federal Reserve recommends submitting files needing monitoring before 4:30pm ET." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:state.held-at-the-operator", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.same-day-statement-identification", "id": "rule.same-day-statement-identification", "rail": "us-ach", "class": "Rule", "name": "Telling same day from next day on Federal Reserve statements and advices", "statement": "On Federal Reserve accounting statements, same day origination and receipt post under their own accounting transaction codes, apart from next day items, with credits and debits totalled separately. FedACH puts no marker in its output files saying which window an entry settles in: the transmission deadlines and an entry's eligibility decide that, and the settlement advices separate the two. Each advice covers one settlement: the first what settles at 13:00 Eastern, the second at 17:00, the third at 18:00, a fourth only for prefunded origination, and an end of day advice for entries posting at 08:30 Eastern on a later settlement date. Files are lettered in the order created (A, B, C) by window and volume, so one bank's A file may arrive with another's B file, a file may mix same day and next day items, forward entries and returns, and advices may not match files one to one, though they always balance to Federal Reserve accounting.", "rests_on": "guidance", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-same-day-ach-faq", "section": "Same Day Entry Fee and Accounting: identifying items on accounting statements; Same Day ACH Transaction Transmission and Settlement; Advices and Balancing", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.ach-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.settlement-same-day-settlement-clock-times", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.settlement-future-dated-settlement-clock-time", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted. The accounting transaction code values themselves are not given on the page.", "confidence": "medium" }, "currency": { "effective_since": "2021-03-19", "effective_to": null, "effective_note": "Describes FedACH with three same day windows, in place since 2021-03-19, per the FAQ updated 2022-03-23.", "source_edition": "Federal Reserve Same Day ACH FAQ (updated 2022-03-23), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.frb-same-day-ach-faq", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms same day items post under their own accounting transaction codes separate from non-same day items with credits and debits totalled separately, that FedACH puts no marker in output files but the settlement advices separate the two by window (advice 1 at 1pm ET, advice 2 at 5pm ET, advice 3 at 6pm ET, a fourth for prefunded origination, and an end of day advice for items posting at 8:30am ET the next day), that output files are lettered A, B, C in the order created, and that advices may not match files one to one though they always balance to the Federal Reserve accounting system." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.settlement-credit-given-for-a-debit-is-not-the-same-as", "id": "rule.settlement-credit-given-for-a-debit-is-not-the-same-as", "rail": "us-ach", "class": "Rule", "name": "Credit given for a debit is not the same as funds collected", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraphs 11.1(a) and 11.1(b)", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:settlement by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:settlement by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing. Merged 2026-09-20: us-ach:rule.decision-points-whether-credit-for-a-debit-can-be-used stated the withholding of credit and the unwinding of a settlement window from the same paragraphs of the same source, Operating Circular 4 paragraphs 11.1(a) and 11.1(b), and was deleted; the us-ach decision-points fact that listed it now lists this record. This record was kept because it is the only one of the three on paragraph 11.1 that states all of it: the credit being available on the settlement date, the Reserve Bank withholding its use, and the reversal of a whole settlement window's debits the following morning. Merged 2026-09-20: us-ach:rule.finality-a-debit-settles-and-credit-for-it-is-not-equally stated the credit becoming available on the settlement date and staying conditional from the same source, Operating Circular 4 paragraph 11.1(a), and was deleted; the us-ach finality fact that listed it now lists this record. Sweep rank 10 paired those two records against each other and both were kept and linked earlier the same day, before this record was found; it states everything both of them said, so both were folded into it and the links between them went with them.", "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": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:settlement, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:state.funds-available", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.settled", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.settlement-unwound", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.settlement-effective-date-windows-are-bounded", "id": "rule.settlement-effective-date-windows-are-bounded", "rail": "us-ach", "class": "Rule", "name": "Effective date windows are bounded", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "Appendix B, paragraph 2.1 table", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:settlement by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:settlement by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:settlement, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.settlement-future-dated-settlement-clock-time", "id": "rule.settlement-future-dated-settlement-clock-time", "rail": "us-ach", "class": "Rule", "name": "Future dated settlement clock time", "statement": "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.", "rests_on": "guidance", "facet": "settlement", "parameters": { "time_window": { "times": [ "08:30" ], "timezone": "America/New_York", "on": "banking_day", "text": "08:30 Eastern on the applicable banking day" } }, "relations": [ { "type": "sourced_from", "to": "us-ach:src.fedach-processing-schedule-2022-09-12", "section": "Future Dated Forward Items table and footnote 4, read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.hours-overnight-windows-for-future-dated-work", "note": "The same 08:30 Eastern settlement event, from the same FedACH Processing Schedule table. That record gives the three overnight transmission windows for future dated files, which this record does not, and restates this record's settlement time without adding to it.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:settlement by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. The typed parameters and the links other than sourced_from were added by the migration from the line's own words and are unchecked.", "confidence": "medium" }, "currency": { "effective_since": "2022-09-12", "effective_to": null, "effective_note": "Split out of us-ach:settlement by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "us-ach:src.fedach-processing-schedule-2022-09-12", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:settlement, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.hours-overnight-windows-for-future-dated-work", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.same-day-risk-pended-batches", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.same-day-statement-identification", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.awaiting-settlement", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.settlement-prefunding-where-a-reserve-bank-requires-it", "id": "rule.settlement-prefunding-where-a-reserve-bank-requires-it", "rail": "us-ach", "class": "Rule", "name": "Prefunding, where a Reserve Bank requires it", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraph 5.3 with Appendix C", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.limits-funding-capacity-can-act-as-a-limit", "note": "The same prefunding provision read as a limit. That record says the effective ceiling is then the settlement account balance rather than any rule figure, which this record does not say.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:settlement by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:settlement by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing. Merged 2026-09-20: us-ach:rule.decision-points-whether-a-bank-must-prefund stated the same prefunding provision of Operating Circular 4, paragraph 5.3, and was deleted; the us-ach decision-points fact that listed it now lists this record. This record was kept because it states the provision in full, adding that where prefunding applies the Reserve Bank steps into the sending bank's settlement obligation, and because its citation names Appendix C as well as the paragraph.", "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": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:settlement, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.limits-funding-capacity-can-act-as-a-limit", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.settlement-same-day-settlement-clock-times", "id": "rule.settlement-same-day-settlement-clock-times", "rail": "us-ach", "class": "Rule", "name": "Same day settlement clock times", "statement": "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).", "rests_on": "guidance", "facet": "settlement", "parameters": { "time_window": { "times": [ "13:00", "17:00", "18:00" ], "timezone": "America/New_York", "on": "banking_day", "text": "13:00, 17:00 or 18:00 Eastern on the day of receipt" } }, "relations": [ { "type": "sourced_from", "to": "us-ach:src.fedach-processing-schedule-2022-09-12", "section": "Same Day Eligible Forward Items table, read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:settlement by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name. The typed parameters and the links other than sourced_from were added by the migration from the line's own words and are unchecked.", "confidence": "medium" }, "currency": { "effective_since": "2022-09-12", "effective_to": null, "effective_note": "Split out of us-ach:settlement by the 2026-09 Orca Core migration; no rule change identified. effective_since is the fact's.", "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": "us-ach:src.fedach-processing-schedule-2022-09-12", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:settlement, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.hours-same-day-credit-funds-availability", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.same-day-statement-identification", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.awaiting-settlement", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.settlement-the-settlement-asset-and-its-hours", "id": "rule.settlement-the-settlement-asset-and-its-hours", "rail": "us-ach", "class": "Rule", "name": "The settlement asset and its hours", "statement": "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.", "rests_on": "guidance", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-abcs-of-ach", "section": "read 2026-09-17", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.fedach-processing-schedule-2022-09-12", "section": "footnote 3 pointing settlement to the Federal Reserve Policy on Payment System Risk", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.hours-how-long-the-network-is-open", "note": "The same settlement hours from the same Nacha page. That record carries the 23 and a quarter hours the network itself is open for processing, which this record does not; this one says settlement happens in central bank money and cites the FedACH Processing Schedule footnote pointing settlement to the Payment System Risk policy.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:settlement by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:settlement by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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": "us-ach:src.nacha-abcs-of-ach", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the ACH Network settles payments four times a day while the Federal Reserve settlement service is open, and that it is closed on federal holidays, weekends, and between 6:30 p.m. and 7:30 a.m. Eastern." }, { "source": "us-ach:src.fedach-processing-schedule-2022-09-12", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms footnote 3, that settlement for ACH items processed by a Reserve Bank under Operating Circular 4 is made at the times set forth in the Federal Reserve Policy on Payment System Risk and the schedule itself." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.hours-how-long-the-network-is-open", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.settled", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.settlement-what-settlement-is", "id": "rule.settlement-what-settlement-is", "rail": "us-ach", "class": "Rule", "name": "What settlement is", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraph 10.2", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:settlement by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:settlement by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:settlement, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:state.settled", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.settlement-which-day-is-the-settlement-day", "id": "rule.settlement-which-day-is-the-settlement-day", "rail": "us-ach", "class": "Rule", "name": "Which day is the settlement day", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "Appendix B, paragraphs 2.1 and 3.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:settlement by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:settlement by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:settlement, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:state.awaiting-settlement", "type": "governed_by", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.settlement-whose-obligation-it-is", "id": "rule.settlement-whose-obligation-it-is", "rail": "us-ach", "class": "Rule", "name": "Whose obligation it is", "statement": "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.", "rests_on": "rule", "facet": "settlement", "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraph 10.1", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the detail lines of us-ach:settlement by the 2026-09 Orca Core migration; the claim and its wording are the fact's, and its sources are those its sourced_from links name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out of us-ach:settlement by the 2026-09 Orca Core migration; no rule change identified. The fact's date belongs to its other lines, so this one is recorded as long-standing.", "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": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:settlement, whose check against this source confirmed this detail line." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.tps-annual-rules-compliance-audit", "id": "rule.tps-annual-rules-compliance-audit", "rail": "us-ach", "class": "Rule", "name": "Annual Rules compliance audit for Third-Party Senders and service providers", "statement": "A Third-Party Sender must have an audit of its compliance with the Nacha rules each year, completed by December 31, like ODFIs, RDFIs and Third-Party Service Providers; a service provider's audit covers the functions it performs for a financial institution or a sender. The audit is run under an audit committee, audit manager, senior officer or an independent examiner or auditor. Proof that it was done is kept for six years and given to Nacha on request. A sender cannot rely on another sender's audit in the chain; each has its own. What the audit covers follows the sender's functions, for example originator identity checks, agreements, exposure limits, return monitoring, authorizations, prenotes, reversals, NOCs and returns; Nacha's page of 2022 says the prescriptive audit list was taken out of Appendix Eight, and a bank's current guide still lists such items.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "us-ach:src.regions-tps-annual-ach-audit-2026-05-07", "section": "who is subject, deadline, who directs it, retention, audit items", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-third-parties-in-the-ach-network", "section": "Rules and Compliance paragraph", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-third-party-sender-roles", "section": "Details: own Rules Compliance Audit; Technical: note on Appendix 8", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.umacha-third-party-services", "section": "Third-Party Audit Requirement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.third-party-sender", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.third-party-service-provider", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.nested-third-party-sender", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.tps-risk-assessment", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted. The December 31 date, the six year retention and who may direct the audit rest on a bank article and a payments association page [Unverified against the rulebook].", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Long-standing requirement; the bar on relying on another sender's audit is explicit from 2022-09-30.", "source_edition": "Regions Bank article of 2026-05-07 and Nacha public pages, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-third-party-sender-roles", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms a Third-Party Sender cannot rely on another sender's Rules Compliance Audit and must conduct its own, and that the prescriptive audit topic list was removed from Appendix Eight of the Rules; UMACHA's public page separately confirms the Nacha Operating Rules require both Third-Party Senders and Third-Party Service Providers performing ACH services for a financial institution to complete this audit by December 31 each year. Does not confirm the six year retention period or the audit committee, audit manager, senior officer or independent examiner or auditor structure named in the record; those rest on the bank guide the record cites, which this check could not open." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.tps-payment-facilitators", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.tps-risk-assessment", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.tps-company-name-and-identification", "id": "rule.tps-company-name-and-identification", "rail": "us-ach", "class": "Rule", "name": "Whose name and identifier a platform puts in the batch header", "statement": "When an intermediary sends entries as a Third-Party Sender, the Company Name field carries the Originator's name, because that is the name the Receiver's bank shows on the statement; on entries it originates in its own name, such as a funding debit or a settlement credit, it puts its own name. The Company Identification that the ODFI registers with Nacha for a sender is the sender's own, and large platforms publish their own company IDs as the ones used for all their users. [Inference] So on a platform's entries the name usually identifies the merchant while the company ID identifies the platform; whether the Nacha rules require or only permit that split was not confirmed.", "rests_on": "guidance", "facet": "messages", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-ops-bulletin-2-2014-third-party-senders", "section": "Payroll and Tuition Processing scenarios, pages 5, 6, 9 and 10", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-third-party-sender-registration", "section": "Details: initial registration information", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.stripe-ach-company-ids", "section": "the two company IDs used for all users", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.third-party-sender", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.tps-which-role-an-intermediary-plays", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "As described in guidance of 2014-12-30 and pages read 2026-09-19; no rule change date identified.", "source_edition": "Nacha ACH Operations Bulletin #2-2014 and public pages, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-ops-bulletin-2-2014-third-party-senders", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms, across the bulletin's payroll processor, tuition processor, property manager, merchant and e-wallet scenarios, that the Company Name field carries the name of the party ultimately being paid or paying so the Receiver's bank can show it on a statement, and that an intermediary originating a debit or credit in its own capacity, such as a payroll processor's funding debit, puts its own name in that field for that entry. Does not confirm that large platforms publish a single Company Identification used across their users; Stripe's company ID page could not be read because it renders its content through client side JavaScript." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.tps-duties-and-warranties", "id": "rule.tps-duties-and-warranties", "rail": "us-ach", "class": "Rule", "name": "What a Third-Party Sender does and warrants in place of the ODFI", "statement": "Because the ODFI usually has no contract with the Originator, the rules put much of the ODFI's work on the Third-Party Sender: checking each Originator's identity before signing it up, setting, reviewing and enforcing exposure limits, watching origination and returns across settlement dates, keeping Originators to permitted entry types, producing proof of authorization, and keeping Originators on track with returns and NOCs. On each entry it sends, it warrants among other things that the entry is authorized and the authorization still stands, that the Originator is not suspended and agreements are in force, and that the entry follows the rules. It warrants that its Originators have accepted an Originator's obligations and must indemnify the ODFI if they fail them, and it must pay for the credits it sends and for certain returned debits.", "rests_on": "rule", "facet": "participants", "parameters": { "liability_holder": { "role": "us-ach:role.third-party-sender", "condition": "an Originator it sends for fails its Originator obligations", "text": "the Third-Party Sender indemnifies its ODFI" } }, "relations": [ { "type": "sourced_from", "to": "us-ach:src.regions-tps-warranties-obligations-2026-08-28", "section": "key obligations; warranties; indemnification", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.bnd-third-party-sender-ach-agreement-2025-06", "section": "Sections 5.D, 6 and 7", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.third-party-sender", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.odfi-oversight-of-third-party-senders", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted. Both sources are secondary; the rulebook sections behind them were not read.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "As described in a bank article of 2026-08-28; no rule change date identified.", "source_edition": "Regions Bank article of 2026-08-28 and Bank of North Dakota form SFN 60650 (06-2025), read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.bnd-third-party-sender-ach-agreement-2025-06", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the sender warrants each entry is authorized and the authorization has not been revoked, that it assumes ODFI and Originator responsibilities under the Rules, that each customer has agreed to assume Originator obligations and the sender must indemnify the ODFI for a customer's failure to perform them, that the sender must identify its customers, and that it agrees to settle for the credit entries it sends and for debit entries returned or dishonored by an RDFI. Regions Bank's page on the same topic could not be checked because the site returned an Incapsula bot detection block rather than the page." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.tps-nested-chain-of-agreements", "id": "rule.tps-nested-chain-of-agreements", "rail": "us-ach", "class": "Rule", "name": "Nested Third-Party Senders and the chain of agreements", "statement": "The ODFI's origination agreement with a Third-Party Sender must say whether the sender may take on nested senders; if it may, the sender must itself have an origination agreement with each nested sender, so agreements run unbroken from ODFI to Originator. The rules set no limit on the number of levels. The ODFI still answers to RDFIs, for example for proof of authorization, however many senders sit in between. These agreement changes applied to agreements made from 2022-09-30 on, without requiring old ones to be re-signed, though ODFIs must tell their senders about the new rules. An ODFI may simply refuse nested senders; at least two banks' public documents say they do.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-third-party-sender-roles", "section": "Technical: Nested Third-Party Sender; Impact", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.regions-tps-warranties-obligations-2026-08-28", "section": "FAQ on nested third-party sender relationships", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.bnd-third-party-sender-ach-agreement-2025-06", "section": "Section 5.E", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.third-party-sender", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.nested-third-party-sender", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.tps-origination-agreements", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.participants-third-party-senders-including-nested-ones", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "2022-09-30", "effective_to": null, "effective_note": "Effective 2022-09-30 for agreements entered into from that date.", "source_edition": "Nacha public rule page for the rule effective 2022-09-30, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-third-party-sender-roles", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the ODFI's origination agreement with a Third-Party Sender must address whether the sender may have Nested Third-Party Senders and, if so, push down the requirement for an origination agreement between the sender and each nested sender; that the rule amendment does not limit the number of levels; and that an ODFI must identify in Nacha's Risk Management Portal which of its senders allow nested senders and provide that information to Nacha on request." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.tps-origination-agreements", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.tps-origination-agreements", "id": "rule.tps-origination-agreements", "rail": "us-ach", "class": "Rule", "name": "What the agreements around a Third-Party Sender contain", "statement": "A Third-Party Sender needs an origination agreement with its ODFI and one with each Originator or nested sender it serves. From the public material read, the ODFI agreement typically has the sender bound by the Nacha rules and applicable law, promise not to send unlawful entries, accept any limits on entry types, and give the ODFI the right to audit it and its Originators and to end or suspend the agreement for a material rules breach. The sender's agreement with each Originator typically binds the Originator to the rules, has it take on an Originator's obligations and warranties, requires a valid authorization for every entry, sets an exposure limit the sender reviews, lets the sender audit it, and gives credit Originators the UCC Article 4A notice. [Unverified] Which of these items the Nacha rules require as a minimum, rather than as one bank's practice, was not confirmed against the rulebook or a Nacha page.", "rests_on": "practice", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "us-ach:src.bnd-third-party-sender-ach-agreement-2025-06", "section": "Sections 2 and 5.C", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.regions-tps-annual-ach-audit-2026-05-07", "section": "audit items on agreements and the UCC Article 4A notice", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.eta-payfacs-ach-2024-05-10", "section": "origination agreements binding the Originator to the rules", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-third-parties-in-the-ach-network", "section": "Rules and Compliance paragraph", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.third-party-sender", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.tps-nested-chain-of-agreements", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted. One bank's agreement form is the main source for contents.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Contents as found in public material read 2026-09-19; no rule change date identified.", "source_edition": "Bank of North Dakota form SFN 60650 (06-2025) and public articles, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.eta-payfacs-ach-2024-05-10", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that under the Nacha Rules a Third-Party Sender must have a compliant origination agreement with each Originator it serves, that the agreement must at minimum include the provisions the Rules require, and that among those it must bind the Originator to the Rules and include the Originator's authorization for the ODFI to originate entries on its behalf. The Bank of North Dakota agreement separately shows an ODFI agreement binding the sender to the Rules and applicable law, giving audit rights over the sender and its customers, and letting the ODFI terminate for a material breach; it does not show a UCC Article 4A notice to credit Originators, so which agreement terms the Rules themselves require as a minimum, beyond what ETA states, is not confirmed." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.tps-nested-chain-of-agreements", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.tps-payment-facilitators", "id": "rule.tps-payment-facilitators", "rail": "us-ach", "class": "Rule", "name": "Payment facilitators and platforms that settle to merchants", "statement": "A payment facilitator or platform has to classify itself leg by leg, as for any intermediary. When it collects ACH debits from a merchant's customers on the merchant's behalf under its own origination agreement with the ODFI, the merchant is the Originator and the platform is a Third-Party Sender of those debits. When it pays the collected money out to the merchant as one settlement credit, it is the Originator of that credit and the merchant its Receiver. If it is a Third-Party Sender it takes on the sender's duties: registration by its ODFI, an annual audit, its own risk assessment and origination agreements with its merchants. [Inference] The mapping of payment facilitators onto Nacha's tuition and dues scenarios is this record's reading; the ETA article states only that a facilitator settling to sub-merchants must work out its role.", "rests_on": "guidance", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-ops-bulletin-2-2014-third-party-senders", "section": "Tuition Processing and Homeowners Association Dues scenarios, pages 7 to 13", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.eta-payfacs-ach-2024-05-10", "section": "role classification for settlement to sub-merchants; obligations of a PayFac that is a Third-Party Sender", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.third-party-sender", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.tps-which-role-an-intermediary-plays", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.tps-registration", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.tps-annual-rules-compliance-audit", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted. Nacha has published no payment facilitator scenario that was found.", "confidence": "low" }, "currency": { "effective_since": "2014-03-21", "effective_to": null, "effective_note": "Applies the Third-Party Sender definition effective 2014-03-21; the ETA article is dated 2024-05-10.", "source_edition": "Nacha ACH Operations Bulletin #2-2014 and ETA article of 2024-05-10, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.eta-payfacs-ach-2024-05-10", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms a payment facilitator must work out its role or classification leg by leg under the Nacha Rules, that a facilitator designated a Third-Party Sender takes on registration, an annual audit and origination agreements with its Originators, and that a Third-Party Sender should never be identified as the Originator for entries it transmits in that capacity. Does not itself state the specific two-leg mapping (merchant as Originator of the collected debits, platform as Originator of the settlement credit); Nacha's 2014 bulletin shows the same general pattern in its tuition processor and e-wallet scenarios, where the intermediary is the Originator only of the entry it sends in its own name." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.tps-which-role-an-intermediary-plays", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.tps-registration", "id": "rule.tps-registration", "rail": "us-ach", "class": "Rule", "name": "ODFIs register their Third-Party Senders with Nacha", "statement": "Every ODFI must either register each Third-Party Sender customer in Nacha's Risk Management Portal or tell Nacha it has none; there is no exemption by size or risk and no charge. Registration covers senders that are the ODFI's direct customers and the nested senders behind them, and gives basic data: the ODFI and its contact, the sender's name and principal place of business, the ODFI routing number used on its entries and the sender's Company Identification numbers. It is due within 30 days of the first entry, or within 10 days of the ODFI learning that a customer is a sender, and changes are due within 45 days. Since 2022-09-30 the ODFI also flags senders that allow nested senders, and on request tells Nacha who those are. When Nacha sees a risk event, it may ask the ODFI for more, due in 10 banking days: trade names, tax ID, addresses, contacts, principals, roughly how many Originators, and whether it sends debits, credits or both. The sender for its part must give its ODFI registration data within 2 banking days of a request and name any other sender it transmits for before transmitting for it. An ODFI that fails to register commits a Class 2 rules violation.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-third-party-sender-registration", "section": "Details, Technical and FAQs; technical note naming Article Two, Subsections 2.15.1 and 2.17.3, Appendix Eight Part 8.4 and Appendix Ten Subparts 10.3.2 and 10.4.7.4 as numbered in 2017", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-third-party-sender-roles", "section": "Technical: registration of Third-Party Senders with Nested Third-Party Senders", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.third-party-sender", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.odfi-oversight-of-third-party-senders", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted. Section numbers are as Nacha's page gave them in 2017 and may have moved since [Unverified].", "confidence": "medium" }, "currency": { "effective_since": "2017-09-29", "effective_to": null, "effective_note": "Registration effective 2017-09-29 with initial registrations due by 2018-03-01; the nested sender flag from 2022-09-30, with a grace period to 2023-03-31.", "source_edition": "Nacha public rule pages for the rules effective 2017-09-29 and 2022-09-30, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-third-party-sender-registration", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms an ODFI must register a Third-Party Sender within 30 days of the first entry, or within 10 days of learning a customer is a sender, that registration updates are due within 45 days of a change, that a sender must give its ODFI registration data within 2 banking days of a request and disclose any other sender it transmits for before doing so, that registration covers direct and nested senders, that failure to register is a Class 2 Rules Violation, that there is no ODFI registration charge, and that Nacha may request supplemental data such as trade names, principals and tax ID within 10 banking days after a defined risk event." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.odfi-oversight-of-third-party-senders", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.tps-payment-facilitators", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.tps-risk-assessment", "id": "rule.tps-risk-assessment", "rail": "us-ach", "class": "Rule", "name": "Every Third-Party Sender does its own ACH risk assessment", "statement": "Since 2022-09-30 the rules say expressly that each Third-Party Sender, nested or not, must carry out a risk assessment of its ACH activity and run a risk management program based on it; senders without one had until 2023-03-31. It cannot adopt another sender's assessment. No method or topic list is prescribed, since senders differ, but Nacha expects the usual families of risk (operational, return, credit, fraud, compliance, reputational) and points senders to the ODFI's own duties, such as due diligence, exposure limits, testing authorizations, monitoring volumes and returns, data security and SEC code specific controls. The ODFI is not required to review the sender's assessment, though it may set policies that push for it.", "rests_on": "rule", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-third-party-sender-roles", "section": "Details and Technical: TPS Risk Assessments; Impact", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.umacha-third-party-services", "section": "Third Party Risk Assessment Requirement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-third-parties-in-the-ach-network", "section": "Rules and Compliance paragraph", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.third-party-sender", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.nested-third-party-sender", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.participants-third-party-senders-including-nested-ones", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.tps-annual-rules-compliance-audit", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted.", "confidence": "medium" }, "currency": { "effective_since": "2022-09-30", "effective_to": null, "effective_note": "Effective 2022-09-30 with a grace period to 2023-03-31 for senders without an assessment.", "source_edition": "Nacha public rule page for the rule effective 2022-09-30, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-third-party-sender-roles", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the rule effective 2022-09-30 makes explicit that every Third-Party Sender, nested or not, must conduct its own ACH risk assessment and implement a risk management program based on it, that a sender cannot rely on another sender's assessment, that senders without one had a grace period to 2023-03-31, that no specific methodology or topic list is prescribed though Nacha points to broad risk categories including operational, return, credit, fraud, compliance and reputational risk, and that ODFIs are not required to review a sender's assessment though they may encourage it." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.tps-annual-rules-compliance-audit", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.tps-which-role-an-intermediary-plays", "id": "rule.tps-which-role-an-intermediary-plays", "rail": "us-ach", "class": "Rule", "name": "Originator, Third-Party Sender or only a service provider: the test", "statement": "Whether a payment intermediary is a Third-Party Sender is decided entry by entry. First find the underlying obligation and whose behalf the intermediary acts on. An intermediary that moves money for someone else is at least a Third-Party Service Provider; it is also a Third-Party Sender when it, rather than the Originator, holds the origination agreement with the ODFI, and only a service provider when the Originator holds that agreement itself. A settlement account the Originator keeps at the ODFI does not change this. Where the intermediary acts in its own name, such as a payroll processor's funding debit to the employer or a tuition processor's daily settlement credit to the university, it is the Originator of that entry; so every Third-Party Sender is a service provider, not every service provider is a sender, and one business can be both Originator and sender in the legs of one payment. A processor that itself contracts through another processor holding the ODFI agreement is a sender too, now called a Nested Third-Party Sender.", "rests_on": "guidance", "facet": "participants", "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-ops-bulletin-2-2014-third-party-senders", "section": "Discussion, pages 1 to 3; Payroll Processing and Tuition Processing scenarios, pages 4 to 10, including the nested processors and settlement accounts notes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-third-parties-in-the-ach-network", "section": "Key Definitions", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.eta-payfacs-ach-2024-05-10", "section": "distinction between Third-Party Service Providers and Third-Party Senders", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.third-party-sender", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.third-party-service-provider", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.tps-payment-facilitators", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.participants-third-party-senders-including-nested-ones", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted 2026-09-19 from the public sources its sourced_from links name, each opened and read that day; the Nacha Operating Rules themselves were not consulted. The 2014 bulletin is guidance, not the rule text.", "confidence": "medium" }, "currency": { "effective_since": "2014-03-21", "effective_to": null, "effective_note": "The definition this test applies took effect 2014-03-21, per Nacha's bulletin of 2014-12-30.", "source_edition": "Nacha ACH Operations Bulletin #2-2014, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-third-parties-in-the-ach-network", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the key definitions: a Third-Party Service Provider provides services related to ACH processing on behalf of another party and may or may not transmit entries directly; a Third-Party Sender is a specific kind of TPSP that acts on behalf of an Originator to transmit entries through an ODFI without a direct agreement between the Originator and the ODFI, so every Third-Party Sender is a service provider but not every service provider is a sender; and a Nested Third-Party Sender originates through another TPS rather than directly with an ODFI." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.tps-company-name-and-identification", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.tps-payment-facilitators", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.unauthorized-return-rate-threshold", "id": "rule.unauthorized-return-rate-threshold", "rail": "us-ach", "class": "Rule", "name": "Unauthorized entry return rate threshold: 0.5 percent", "statement": "An Originator's rate of debit returns for the unauthorized reasons linked to it must stay at or below 0.5 percent; above it is a rules violation.", "rests_on": "rule", "facet": "return", "parameters": { "limit": { "rate": 0.5, "unit": "percent", "measured_over": "debit entries over the preceding 60 days [Unverified]", "text": "0.5%" } }, "relations": [ { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-differentiating-unauthorized-return-reasons", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Split out of the rates block of corpus/us-ach/meta.json and the counts_toward lists of the us-ach codes by the 2026-09 Orca Core migration. The sources are those its relations name.", "confidence": "medium" }, "currency": { "effective_since": "2015-09-18", "effective_to": null, "effective_note": "Reduced to 0.5 percent effective 2015-09-18, per the effective notes of us-ach:R05, R07, R29 and R51.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-differentiating-unauthorized-return-reasons", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-16", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:R11, whose checks against this source confirmed that R11 counts toward the 0.5 percent unauthorized return rate from 2020-04-01." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R05", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R07", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R10", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R11", "type": "counts_toward", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R29", "type": "counts_toward", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R51", "type": "counts_toward", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.web-debit-account-validation", "id": "rule.web-debit-account-validation", "rail": "us-ach", "class": "Rule", "name": "WEB debits: account validation is part of the required fraud screening", "statement": "An Originator of WEB debits must screen them with a commercially reasonable fraudulent transaction detection system, and since 2021-03-19 that system must include validating the account to be debited. Validation is due the first time an account number is used for a WEB debit and again whenever the account number changes. In Nacha's reading, fraud screening that leaves out an account validation step falls short of the rule, so debiting a new account by WEB with no validation at all is a breach. Nacha held off enforcement for a further year for parties working toward compliance in good faith, which is why processors date enforcement to 2022-03-19.", "rests_on": "rule", "facet": "decision-points", "parameters": { "eligibility": { "direction": "debit", "account_type": "consumer", "transaction_types": [ "us-ach:txn.web" ], "excludes": [], "text": "WEB debits, at the first use of an account number and at each later change to it" } }, "relations": [ { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.web", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-supplementing-fraud-detection-web-debits", "section": "Details and FAQs: effective date, scope, enforcement grace period; read 2026-09-19", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.tompkins-originating-ach-quick-reference", "section": "Originating WEB Entries: obligations and Originator warranty 2", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.stripe-nacha-validation-rule-faq", "section": "rule summary and enforcement date", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.web-validation-what-it-confirms", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.web-validation-methods", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Nacha's public rule page and FAQs for the WEB debit account validation rule, read 2026-09-19, and the other sources its sourced_from links name; the Nacha Operating Rules text was not consulted, so no rulebook section is cited.", "confidence": "medium" }, "currency": { "effective_since": "2021-03-19", "effective_to": null, "effective_note": "Drafted on 2026-09-19. Effective 2021-03-19 after two extensions of an original 2020-01-01 date; Nacha did not enforce it for a further year against parties working toward compliance in good faith.", "source_edition": "Nacha public rule pages read 2026-09-19; Nacha Operating Rules not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-supplementing-fraud-detection-web-debits", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the 2021-03-19 effective date, that validation applies to the first use of an account number and to any change, that a system without validation does not comply, and the one year non-enforcement grace period for good faith compliance efforts." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:mandate.web-debit-authorization", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.authorization-web", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.web-validation-after-noc", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.web-validation-what-it-confirms", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.web-validation-after-noc", "id": "rule.web-validation-after-noc", "rail": "us-ach", "class": "Rule", "name": "WEB account validation: a number supplied by a Notification of Change", "statement": "When an account number changes because the RDFI sent a Notification of Change, the Originator need not validate the new number before debiting it: the RDFI warrants that the information in its NOC is accurate.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.web", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-supplementing-fraud-detection-web-debits", "section": "FAQs: account numbers updated by a NOC; read 2026-09-19", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.tompkins-originating-ach-quick-reference", "section": "Notification of Change: the receiving bank's warranty", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.web-debit-account-validation", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Nacha's public rule page and FAQs for the WEB debit account validation rule, read 2026-09-19, and the other sources its sourced_from links name; the Nacha Operating Rules text was not consulted, so no rulebook section is cited.", "confidence": "medium" }, "currency": { "effective_since": "2021-03-19", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from the public sources its sourced_from links name; no rule change identified after the date given.", "source_edition": "Nacha public rule pages read 2026-09-19; Nacha Operating Rules not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-supplementing-fraud-detection-web-debits", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that an Originator need not revalidate an account number changed by an RDFI's Notification of Change, because the RDFI's warranty on the corrected data serves as the validation." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.web-validation-commercially-reasonable", "id": "rule.web-validation-commercially-reasonable", "rail": "us-ach", "class": "Rule", "name": "WEB account validation: what makes a method commercially reasonable", "statement": "Nacha sets no coverage percentage. Whether a validation approach is commercially reasonable turns on the facts: how risky the debits are, the Originator's own fraud and return history, how much of the account population a service reaches, what is known about fraud among the accounts it misses, and what other controls compensate. A method can be commercially reasonable without covering every account. When a check returns no result, neither a pass nor a fail, the Originator may still send the WEB debit if that fits its commercially reasonable detection system for its risk profile.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.web", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-supplementing-fraud-detection-web-debits", "section": "FAQs: coverage below 100 percent, the no hit result, factors to weigh; read 2026-09-19", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.web-validation-methods", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Nacha's public rule page and FAQs for the WEB debit account validation rule, read 2026-09-19, and the other sources its sourced_from links name; the Nacha Operating Rules text was not consulted, so no rulebook section is cited.", "confidence": "medium" }, "currency": { "effective_since": "2021-03-19", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from the public sources its sourced_from links name; no rule change identified after the date given.", "source_edition": "Nacha public rule pages read 2026-09-19; Nacha Operating Rules not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-supplementing-fraud-detection-web-debits", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that Nacha sets no coverage percentage, lists the risk, history, no-hit rate and compensating control factors that decide commercial reasonableness, and confirms a WEB debit may still be sent after a no-hit result under a commercially reasonable system." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.web-validation-methods", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.web-validation-existing-accounts", "id": "rule.web-validation-existing-accounts", "rail": "us-ach", "class": "Rule", "name": "WEB account validation: accounts already in use", "statement": "The rule does not reach back: accounts already used for WEB debits before it took effect need not be validated again. An account that has already been used successfully for earlier payments, whether by WEB or by another SEC code, needs no fresh validation when a new WEB authorization is taken for it, because a successful payment history is itself an accepted method.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.web", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-supplementing-fraud-detection-web-debits", "section": "FAQs: existing customers and accounts with prior payments; read 2026-09-19", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.web-validation-methods", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Nacha's public rule page and FAQs for the WEB debit account validation rule, read 2026-09-19, and the other sources its sourced_from links name; the Nacha Operating Rules text was not consulted, so no rulebook section is cited.", "confidence": "medium" }, "currency": { "effective_since": "2021-03-19", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from the public sources its sourced_from links name; no rule change identified after the date given.", "source_edition": "Nacha public rule pages read 2026-09-19; Nacha Operating Rules not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-supplementing-fraud-detection-web-debits", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the rule applies going forward only, that an account number already used successfully for WEB or non-WEB debits needs no fresh validation for a new WEB authorization, and that a changed account number not previously used must still be validated." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:rule.web-validation-methods", "id": "rule.web-validation-methods", "rail": "us-ach", "class": "Rule", "name": "WEB account validation: no method or vendor is prescribed", "statement": "The rule names no required method or provider. The approaches Nacha's FAQs accept are: a record of earlier successful payments to the account; ACH based checks, meaning a prenotification or micro-entries; and outside services, meaning a validation service from the ODFI or a third party, account validation through an API, or an account scoring service. An Originator may combine several to cover more accounts. Whatever is chosen has to be commercially reasonable for the Originator's risk.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.web", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-supplementing-fraud-detection-web-debits", "section": "FAQs: acceptable methods; read 2026-09-19", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.tompkins-originating-ach-quick-reference", "section": "Originating WEB Entries: acceptable validation methods", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.web-validation-commercially-reasonable", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.web-validation-prenote-and-micro-entry-results", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Nacha's public rule page and FAQs for the WEB debit account validation rule, read 2026-09-19, and the other sources its sourced_from links name; the Nacha Operating Rules text was not consulted, so no rulebook section is cited.", "confidence": "medium" }, "currency": { "effective_since": "2021-03-19", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from the public sources its sourced_from links name; no rule change identified after the date given.", "source_edition": "Nacha public rule pages read 2026-09-19; Nacha Operating Rules not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-supplementing-fraud-detection-web-debits", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that no method or vendor is prescribed and that prenotification, micro-entry verification, ODFI or third party validation services, API based checks, scoring services and a history of successful payments are all accepted approaches an Originator may combine." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.practice-instant-verification-and-micro-deposits", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.web-debit-account-validation", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.web-validation-commercially-reasonable", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.web-validation-existing-accounts", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.web-validation-prenote-and-micro-entry-results", "id": "rule.web-validation-prenote-and-micro-entry-results", "rail": "us-ach", "class": "Rule", "name": "WEB account validation: what silence means after a prenote and after micro-entries", "statement": "For the WEB validation duty, an Originator that sends a prenote may treat the lack of any return or NOC by the end of the return and NOC period as the RDFI having confirmed that the account number is open and can take entries; Nacha cautions that relying on this may not be commercially reasonable for every business or risk profile. Micro-entries work the other way: silence proves nothing, and live entries may follow only after the Receiver has confirmed the micro-entry details with the Originator.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.web", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.prenote", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.micro-entry", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-supplementing-fraud-detection-web-debits", "section": "FAQs: prenote with no response; micro-entries; read 2026-09-19", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.prenote-wait-before-live-entries", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.micro-entries-receiver-confirmation", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Nacha's public rule page and FAQs for the WEB debit account validation rule, read 2026-09-19, and the other sources its sourced_from links name; the Nacha Operating Rules text was not consulted, so no rulebook section is cited.", "confidence": "medium" }, "currency": { "effective_since": "2021-03-19", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from the public sources its sourced_from links name; no rule change identified after the date given.", "source_edition": "Nacha public rule pages read 2026-09-19; Nacha Operating Rules not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-supplementing-fraud-detection-web-debits", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms that a prenote with no return or NOC by the end of the period may be treated as validation though it may not suit every risk profile, and that for micro-entries silence proves nothing so live entries may follow only once the Receiver has confirmed the amounts with the Originator." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.micro-entries-receiver-confirmation", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.web-validation-methods", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.web-validation-what-it-confirms", "id": "rule.web-validation-what-it-confirms", "rail": "us-ach", "class": "Rule", "name": "WEB account validation: open and able to take entries, not ownership", "statement": "At a minimum, validation must show that the account is a legitimate open account able to receive ACH entries. The rule does not require confirming that the person giving the authorization owns the account; an Originator may add an ownership check where its own risk calls for one.", "rests_on": "rule", "facet": "decision-points", "relations": [ { "type": "binds", "to": "us-ach:role.originator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.web", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-supplementing-fraud-detection-web-debits", "section": "FAQs: what validation means; read 2026-09-19", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.stripe-nacha-validation-rule-faq", "section": "validation versus verification", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.web-debit-account-validation", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Nacha's public rule page and FAQs for the WEB debit account validation rule, read 2026-09-19, and the other sources its sourced_from links name; the Nacha Operating Rules text was not consulted, so no rulebook section is cited.", "confidence": "medium" }, "currency": { "effective_since": "2021-03-19", "effective_to": null, "effective_note": "Drafted on 2026-09-19 from the public sources its sourced_from links name; no rule change identified after the date given.", "source_edition": "Nacha public rule pages read 2026-09-19; Nacha Operating Rules not consulted", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-supplementing-fraud-detection-web-debits", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-2026-09-19", "notes": "Confirms the minimum standard is that the account is open and can accept ACH entries, that ownership confirmation is not required, and that an Originator may add its own ownership check where its risk profile calls for one." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.web-debit-account-validation", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:rule.written-statement-of-unauthorized-debit", "id": "rule.written-statement-of-unauthorized-debit", "rail": "us-ach", "class": "Rule", "name": "Written Statement of Unauthorized Debit", "statement": "For the return reasons linked to it, the RDFI returns the entry only on a written statement from the Receiver that the debit was not authorized or did not follow its authorization.", "rests_on": "rule", "facet": "return", "relations": [ { "type": "binds", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-differentiating-unauthorized-return-reasons", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.return-what-the-consumer-has-to-sign", "note": "The same written statement requirement, from other sources. That record rests on a bank's rules awareness guide and adds that the originator may obtain a copy of the statement through its own bank, which this record does not cover; this one rests on Nacha's public rule page and a bank's return reason table and is the record the reason codes link to.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Split out of the written statement flag of us-ach:R05, us-ach:R07, us-ach:R10, us-ach:R11, us-ach:R37, us-ach:R51 and us-ach:R53 by the 2026-09 Orca Core migration; the claim is theirs. The sources are those its relations name.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Split out by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "checked_on": "2026-09-18", "checked_by": "validator-sonnet-2026-09-18", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:R05, us-ach:R07, us-ach:R51 and us-ach:R53, whose checks against this source confirmed the written statement of unauthorized debit requirement." }, { "source": "us-ach:src.nacha-differentiating-unauthorized-return-reasons", "checked_on": "2026-09-17", "checked_by": "validator-sonnet-2026-09-16", "notes": "Carried over by the 2026-09 Orca Core migration from us-ach:R10 and us-ach:R11, whose checks against this source confirmed the written statement of unauthorized debit requirement." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:exc.return", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.return-what-the-consumer-has-to-sign", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.returned", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R05", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R07", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R10", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R11", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R37", "type": "governed_by", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R51", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R53", "type": "governed_by", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.androscoggin-ach-block-filter-appendix-2021-07", "id": "src.androscoggin-ach-block-filter-appendix-2021-07", "rail": "us-ach", "class": "RuleSource", "name": "Androscoggin Bank, Business and Government Services Master Agreement, ACH Block and Filter Service Appendix", "summary": "A bank's published contract for its ACH block and filter service: the block and filter elections for debits and for credits, the exception listing and its pay or return decision, the default that applies when nothing is decided, and the rules a customer may whitelist on.", "publisher": "Androscoggin Bank", "url": "https://www.androscogginbank.com/wp-content/uploads/2023/12/711-ACH-Block-Filter-Appendix.pdf", "source_class": "secondary", "kind": "service_agreement", "edition": "form AB 711, revision 7/2021, as read 2026-09-20", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The bank's own published form, downloaded from androscogginbank.com and read in full 2026-09-20 for the debit block question in the OC-5 us-ach coverage gaps. It is one bank's contract, not a network rule, which is why it is secondary.", "confidence": "medium" }, "currency": { "effective_since": "2021-07-01", "effective_to": null, "effective_note": "A RuleSource describes one edition of one document. The form carries a revision of 7/2021 with no day, recorded here as the first of that month; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "form AB 711, revision 7/2021, as read 2026-09-20", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.decision-points-blocking-or-filtering-incoming-debits", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.return-what-a-blocked-debit-comes-back-as", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.bank-of-north-dakota-ach-overview-2024", "id": "src.bank-of-north-dakota-ach-overview-2024", "rail": "us-ach", "class": "RuleSource", "name": "Bank of North Dakota, Automated Clearing House Overview, 2024", "summary": "A state-owned bank's public overview of ACH origination for its customers, covering Notifications of Change, refusal of an NOC, and the dishonored and contested dishonored return codes.", "publisher": "Bank of North Dakota", "url": "https://bnd.nd.gov/pdf/cashplus_ach_overview.pdf", "source_class": "secondary", "kind": "bank_guide", "edition": "2024 edition, per its holiday schedule; PDF created 2024-06-26", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, opened and read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by a drafting session on 2026-09-19. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "2024 edition, per its holiday schedule; PDF created 2024-06-26", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:exc.contested-dishonored-return", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:exc.dishonored-return", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:exc.refused-notification-of-change", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.contest-window-2-banking-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.dishonor-window-5-banking-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.noc-originator-applies-the-change", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.noc-window-2-banking-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.bmo-ach-return-reason-codes-2025-05", "id": "src.bmo-ach-return-reason-codes-2025-05", "rail": "us-ach", "class": "RuleSource", "name": "ACH Return Reason Codes (BMO Treasury and Payment Solutions, May 2025)", "summary": "A bank's public list of US ACH return reason codes with time frames; validators checked us-ach code definitions and return timing against it.", "publisher": "BMO Treasury and Payment Solutions", "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", "kind": "bank_guide", "edition": "May 2025, per its title", "access": "open", "consulted_on": "2026-09-18", "relations": [], "basis": { "sources": "Described from the corroboration entries of the us-ach reason codes that were checked against it (R13, R17, R26, R28, R33, R37, R38); the document was not re-read for this record.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by the 2026-09 Orca Core migration from the us-ach reason code corroborations. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "May 2025, per its title", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.iat-gateway-only-return-codes", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.noc-window-2-banking-days", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.return-window-2-banking-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.return-window-60-calendar-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.return-window-operator-reject", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.bnd-third-party-sender-ach-agreement-2025-06", "id": "src.bnd-third-party-sender-ach-agreement-2025-06", "rail": "us-ach", "class": "RuleSource", "name": "Bank of North Dakota, Third-Party Sender Automated Clearing House (ACH) Agreement, SFN 60650 (06-2025)", "summary": "A public bank form of the origination agreement between an ODFI and a Third-Party Sender, including what the sender's agreements with its customers must contain.", "publisher": "Bank of North Dakota", "url": "https://bnd.nd.gov/wp-content/uploads/third_party_sender_ach_agreement.pdf", "source_class": "secondary", "kind": "pdf_document", "edition": "form SFN 60650 revision 06-2025, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, opened and read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2025-06-01", "effective_to": null, "effective_note": "Created by a drafting session on 2026-09-19. One bank's contract form, dated by its revision month. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "form SFN 60650 revision 06-2025, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.tps-duties-and-warranties", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.tps-nested-chain-of-agreements", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.tps-origination-agreements", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "id": "src.cbs-bank-ach-return-reason-codes-2025-03", "rail": "us-ach", "class": "RuleSource", "name": "CBS Bank, Quick Reference Guide: ACH Return Reason Codes and Time Frames, March 2025", "summary": "A bank's public quick reference to ACH return reason codes and their time frames, including the ACH Operator rejects and the codes federal agencies use on ENR entries; validators checked us-ach code definitions, windows and written statement requirements against it.", "publisher": "CBS Bank", "url": "https://www.cbsbank.com/wp-content/uploads/2025/03/ACH-Return-Reason-Codes.pdf", "source_class": "secondary", "kind": "bank_guide", "edition": "March 2025, per its title", "access": "open", "consulted_on": "2026-09-18", "relations": [], "basis": { "sources": "Described from the corroboration entries of the us-ach reason codes that were checked against it (R01, R02, R03, R04, R05, R06, R07, R08, R09, R12, R16, R17, R18, R19, R20, R21, R22, R24, R25, R27, R29, R31, R33, R35, R37, R38, R39, R50, R51, R52, R53); the document was not re-read for this record.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by the 2026-09 Orca Core migration from the us-ach reason code corroborations. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "March 2025, per its title", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:exc.contested-dishonored-return", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:exc.dishonored-return", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:exc.notification-of-change", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:exc.refused-notification-of-change", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.contest-window-2-banking-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.dishonor-codes-exclude-iat", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.dishonor-window-5-banking-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.iat-foreign-exchange-fields", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-gateway-agreement-with-odfi", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-gateway-only-return-codes", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-no-dishonored-returns", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.noc-corrected-data-layout", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.noc-odfi-passes-it-on-within-2-banking-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.noc-originator-applies-the-change", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.noc-window-2-banking-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.return-window-2-banking-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.return-window-60-calendar-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.return-window-late-by-agreement", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.return-window-odfi-request", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.return-window-operator-reject", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.written-statement-of-unauthorized-debit", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.cfpb-reg-e-interpretations-coverage", "id": "src.cfpb-reg-e-interpretations-coverage", "rail": "us-ach", "class": "RuleSource", "name": "CFPB, Official Interpretations to Regulation E section 1005.3, Coverage", "summary": "The Bureau's official commentary on what Regulation E covers, including the comments on a fee a payee collects electronically after a payment or check is returned unpaid and on the authorization such a fee needs.", "publisher": "Consumer Financial Protection Bureau", "url": "https://www.consumerfinance.gov/rules-policy/regulations/1005/Interp-3/", "source_class": "authoritative_primary", "kind": "official_interpretation", "edition": "current version on consumerfinance.gov as read 2026-09-20", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The Bureau's own page for the Official Interpretations to 12 CFR 1005.3, read 2026-09-20 for the returned payment fee question in the OC-5 us-ach coverage gaps.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "A RuleSource describes one edition of one document. The Bureau publishes the interpretations as a living page with no edition date, so the read date stands for the edition; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "current version on consumerfinance.gov as read 2026-09-20", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.consumer-law-a-returned-payment-fee-is-its-own-debit", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.commerce-bank-ach-return-noc-tran-codes-2022-11", "id": "src.commerce-bank-ach-return-noc-tran-codes-2022-11", "rail": "us-ach", "class": "RuleSource", "name": "Commerce Bank, ACH Return, NOC, and Tran Codes, November 2022", "summary": "A bank's public table of ACH return codes, dishonored return codes, NOC codes with the layout of their corrected data, and transaction codes.", "publisher": "Commerce Bank", "url": "https://www.commercebank.com/-/media/cb/pdf/business/commerce-connections/noccodes.pdf", "source_class": "secondary", "kind": "bank_guide", "edition": "PDF created 2022-11-28, per its document properties; the page carries no edition date", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, opened and read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by a drafting session on 2026-09-19. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "PDF created 2022-11-28, per its document properties; the page carries no edition date", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.dishonor-window-5-banking-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.format-enr-entry-codes", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-transaction-codes", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.noc-corrected-data-layout", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.noc-window-2-banking-days", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.ecfr-31-cfr-1010-410", "id": "src.ecfr-31-cfr-1010-410", "rail": "us-ach", "class": "RuleSource", "name": "31 CFR 1010.410, Records to be made and retained by financial institutions", "summary": "The Bank Secrecy Act recordkeeping and travel rule section: what a financial institution must keep for a transmittal of funds of 3,000 dollars or more and what it must pass on to the next institution in the chain.", "publisher": "Financial Crimes Enforcement Network, as published in the Electronic Code of Federal Regulations", "url": "https://www.ecfr.gov/current/title-31/subtitle-B/chapter-X/part-1010/subpart-D/section-1010.410", "source_class": "authoritative_primary", "kind": "regulation", "edition": "current text on ecfr.gov as read 2026-09-20; the section's source note reads 75 FR 65812, Oct. 26, 2010, as amended at 81 FR 76864, Nov. 4, 2016", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The current text of the section, read 2026-09-20 through the eCFR's own content renderer for title 31, chapter X, part 1010, section 1010.410, for the travel rule threshold question in the OC-5 us-ach coverage gaps.", "confidence": "high" }, "currency": { "effective_since": "2016-11-04", "effective_to": null, "effective_note": "A RuleSource describes one edition of one document. The date is the latest amendment the section's own source note gives; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "current text on ecfr.gov as read 2026-09-20", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.messages-the-travel-rule-threshold-and-what-an-iat-carries", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.ecfr-31-cfr-1020-410", "id": "src.ecfr-31-cfr-1020-410", "rail": "us-ach", "class": "RuleSource", "name": "31 CFR 1020.410, Records to be made and retained by banks", "summary": "The Bank Secrecy Act recordkeeping section for banks, including the list of funds transfers the travel rule does not reach, such as those between named kinds of institution or government body and those moving between one person's own accounts at one bank.", "publisher": "Financial Crimes Enforcement Network, as published in the Electronic Code of Federal Regulations", "url": "https://www.ecfr.gov/current/title-31/subtitle-B/chapter-X/part-1020/subpart-D/section-1020.410", "source_class": "authoritative_primary", "kind": "regulation", "edition": "current text on ecfr.gov as read 2026-09-20", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The current text of the section, read 2026-09-20 through the eCFR's own content renderer for title 31, chapter X, part 1020, section 1020.410, for the exception list that 31 CFR 1010.410(f)(4) points at.", "confidence": "high" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "A RuleSource describes one edition of one document. The read did not capture the section's source note, so no amendment date is claimed; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "current text on ecfr.gov as read 2026-09-20", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.messages-the-travel-rule-threshold-and-what-an-iat-carries", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.eta-payfacs-ach-2024-05-10", "id": "src.eta-payfacs-ach-2024-05-10", "rail": "us-ach", "class": "RuleSource", "name": "Electronic Transactions Association, ETA Expert Insights: Key Considerations for PayFacs in ACH Transactions, 2024-05-10", "summary": "An industry association's article on how a payment facilitator should classify itself under the Nacha rules and what follows if it is a Third-Party Sender.", "publisher": "Electronic Transactions Association", "url": "https://electran.org/news/eta-expert-insights-key-considerations-for-payfacs-in-ach-transactions/", "source_class": "secondary", "kind": "web_page", "edition": "article dated 2024-05-10, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, opened and read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2024-05-10", "effective_to": null, "effective_note": "Created by a drafting session on 2026-09-19. Read through a fetch tool, since the site blocks direct download. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "article dated 2024-05-10, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.tps-origination-agreements", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.tps-payment-facilitators", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.tps-which-role-an-intermediary-plays", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.fedach-processing-schedule-2022-09-12", "id": "src.fedach-processing-schedule-2022-09-12", "rail": "us-ach", "class": "RuleSource", "name": "FedACH Processing Schedule, effective September 12, 2022", "summary": "The Reserve Banks' table of FedACH transmission deadlines, distribution targets and settlement times, with footnotes.", "publisher": "Federal Reserve Banks", "url": "https://www.frbservices.org/resources/resource-centers/same-day-ach/fedach-processing-schedule.html", "source_class": "authoritative_primary", "kind": "processing_schedule", "edition": "schedule effective 2022-09-12, as read 2026-09-17", "access": "open", "consulted_on": "2026-09-18", "relations": [], "basis": { "sources": "Described by the 2026-09 Orca Core migration from the citations and checks of us-ach:hours, us-ach:limits, us-ach:return and us-ach:settlement, which name it; the URL was confirmed to resolve on 2026-09-19 with a matching page title, and the document was not re-read for this record.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by the 2026-09 Orca Core migration from the us-ach rail fact citations. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "schedule effective 2022-09-12, as read 2026-09-17", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.hours-overnight-windows-for-future-dated-work", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.hours-return-deadlines-follow-the-same-clock", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.hours-same-day-transmission-deadlines", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.limits-no-published-ceiling-on-non-same-day-entries", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.return-how-a-return-settles", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.settlement-future-dated-settlement-clock-time", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.settlement-same-day-settlement-clock-times", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.settlement-the-settlement-asset-and-its-hours", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.ffiec-bsa-aml-ofac-overview", "id": "src.ffiec-bsa-aml-ofac-overview", "rail": "us-ach", "class": "RuleSource", "name": "FFIEC BSA/AML Examination Manual, Office of Foreign Assets Control overview, as published by OFAC", "summary": "The examination manual's OFAC chapter, posted by OFAC itself, covering what an OFAC compliance programme is expected to hold, who screens a domestic ACH entry, how a batched file and an on-us entry are treated, the tighter position on cross-border ACH, and responsibility for a third party doing the screening.", "publisher": "Federal Financial Institutions Examination Council, posted by the Office of Foreign Assets Control", "url": "https://ofac.treasury.gov/media/15666/download?inline=", "source_class": "public_primary", "kind": "examination_manual", "edition": "the chapter as posted on ofac.treasury.gov, its pages footed 8/24/2007, read 2026-09-20", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The document OFAC itself posts on ofac.treasury.gov, read in full 2026-09-20 for the sanctions screening questions in the OC-5 us-ach coverage gaps. The FFIEC has revised other chapters of the manual since; this chapter's own pages carry the 2007 date and no later one, and the corpus does not claim it is the newest wording the FFIEC publishes.", "confidence": "medium" }, "currency": { "effective_since": "2007-08-24", "effective_to": null, "effective_note": "A RuleSource describes one edition of one document. The date is the one footed on the chapter's pages; its status stays draft and the monthly watch dates it through consulted_on and should check whether the FFIEC has issued a newer OFAC chapter.", "source_edition": "FFIEC BSA/AML Examination Manual, OFAC overview, pages footed 8/24/2007, as read 2026-09-20", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.liability-outsourced-screening-stays-the-bank-s-problem", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.participants-gateway-screening-does-not-move-the-duty", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.participants-who-screens-a-domestic-entry-for-sanctions", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.fhb-ach-debit-block-2024-10-07", "id": "src.fhb-ach-debit-block-2024-10-07", "rail": "us-ach", "class": "RuleSource", "name": "First Hawaiian Bank, The Power of ACH Debit Block", "summary": "A bank's short public explanation of an ACH debit block for a business customer: the customer names the parties allowed to debit, and everything else is blocked and returned.", "publisher": "First Hawaiian Bank", "url": "https://www.fhb.com/en/resource-center/small-business/the-power-of-ach-debit-block", "source_class": "secondary", "kind": "explainer", "edition": "posted 2024-10-07, as read 2026-09-20", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The bank's own public page on fhb.com, read 2026-09-20. It is one bank's product description, which is why it is secondary, and it is short: it does not say what a filter matches on or what return code a blocked debit draws.", "confidence": "medium" }, "currency": { "effective_since": "2024-10-07", "effective_to": null, "effective_note": "A RuleSource describes one edition of one document. The page gives its own posting date; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "posted 2024-10-07, as read 2026-09-20", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.decision-points-blocking-or-filtering-incoming-debits", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.fhb-ach-noc-reason-codes", "id": "src.fhb-ach-noc-reason-codes", "rail": "us-ach", "class": "RuleSource", "name": "First Hawaiian Bank, Notification of Change Reason Codes", "summary": "A bank's public one page list of the common NOC change codes, with the Originator's duty to apply a change and the section of the Nacha rules it cites for it.", "publisher": "First Hawaiian Bank", "url": "https://www.fhb.com/sites/default/files/2020-11/ACH_NOC_Codes.pdf", "source_class": "secondary", "kind": "bank_guide", "edition": "PDF last modified 2020-05-01, per its document properties", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, opened and read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by a drafting session on 2026-09-19. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "PDF last modified 2020-05-01, per its document properties", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.noc-originator-applies-the-change", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.fhb-ach-return-reason-codes", "id": "src.fhb-ach-return-reason-codes", "rail": "us-ach", "class": "RuleSource", "name": "ACH Return Reason Codes (First Hawaiian Bank)", "summary": "A bank's public table of ACH return reason codes with a return time frame and returning party for each; validators checked us-ach code definitions and return windows against it.", "publisher": "First Hawaiian Bank", "url": "https://www.fhb.com/sites/default/files/2020-11/ACH_RET_Codes.pdf", "source_class": "secondary", "kind": "bank_guide", "edition": "PDF whose URL path dates it to November 2020 [Inference]", "access": "open", "consulted_on": "2026-09-18", "relations": [], "basis": { "sources": "Described from the corroboration entries of the us-ach reason codes that were checked against it (R01, R02, R03, R04, R05, R06, R07, R08, R09, R12, R16, R20, R21, R22, R24, R29, R31); the document was not re-read for this record.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by the 2026-09 Orca Core migration from the us-ach reason code corroborations. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "PDF whose URL path dates it to November 2020 [Inference]", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.return-window-2-banking-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.return-window-60-calendar-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.return-window-late-by-agreement", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.return-window-odfi-request", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.first-citizens-nacha-file-specifications-2024-02", "id": "src.first-citizens-nacha-file-specifications-2024-02", "rail": "us-ach", "class": "RuleSource", "name": "First Citizens Bank, NACHA File Specifications: PPD, CCD, and CTX with Addenda, published 02/2024", "summary": "A bank's specification for files its originating customers send it: record layouts for PPD, CCD and CTX, best practices on padding, fill and line endings, transaction codes and the routing number check digit.", "publisher": "First Citizens Bank", "url": "https://www.firstcitizens.com/content/dam/firstcitizens/pdfs/commercial/commercial-advantage/nacha-file-specs.pdf", "source_class": "secondary", "kind": "pdf_document", "edition": "published 02/2024 (Rev 02/2024), 15 pages, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "Opened and read in full on 2026-09-19 for the file format drafting.", "confidence": "low" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "One bank's intake specification; where it differs from another bank's, the difference is the bank's own requirement. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "published 02/2024 (Rev 02/2024), 15 pages, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.format-blocking-and-padding", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-enr-entry-codes", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-field-fill-conventions", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-record-line-ending", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-transaction-codes", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.frb-day-of-mourning-2018-12-03", "id": "src.frb-day-of-mourning-2018-12-03", "rail": "us-ach", "class": "RuleSource", "name": "Federal Reserve Board press release of December 3, 2018, on the national day of mourning", "summary": "The Board's announcement that its own offices in Washington would close for the national day of mourning on 2018-12-05 while Federal Reserve Bank payment systems ran normally.", "publisher": "Board of Governors of the Federal Reserve System", "url": "https://www.federalreserve.gov/newsevents/pressreleases/other20181203a.htm", "source_class": "authoritative_primary", "kind": "press_release", "edition": "released 2018-12-03, as read 2026-09-20", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The Board's own press release on federalreserve.gov, read 2026-09-20 as a worked case of how a short notice federal closure was handled.", "confidence": "high" }, "currency": { "effective_since": "2018-12-03", "effective_to": null, "effective_note": "A RuleSource describes one edition of one document. This one is a dated announcement about a single day and will not be revised; the watch keeps it only as the precedent it records.", "source_edition": "released 2018-12-03, as read 2026-09-20", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.hours-a-day-off-the-holiday-list-is-still-a-banking-day", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.frb-derived-returns-nocs-faq", "id": "src.frb-derived-returns-nocs-faq", "rail": "us-ach", "class": "RuleSource", "name": "Federal Reserve Financial Services, Derived Returns and Notifications of Change Frequently Asked Questions", "summary": "The Federal Reserve Banks' public answers on the FedLine Web tool that lets an RDFI create single returns, NOCs, dishonored and contested dishonored returns and refused NOCs through FedACH.", "publisher": "Federal Reserve Banks", "url": "https://www.frbservices.org/resources/financial-services/ach/faq/derived-returns-nocs.html", "source_class": "public_primary", "kind": "faq_page", "edition": "web page as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, opened and read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by a drafting session on 2026-09-19. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "web page as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.noc-more-than-one-per-entry", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.operator-derives-dishonors-and-contests", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.participants-only-the-receiving-bank-may-derive-a-return-or-noc", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.return-the-operator-stops-a-second-return-it-can-see", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.frb-dishonored-return-fax-form-instructions-2024-04", "id": "src.frb-dishonored-return-fax-form-instructions-2024-04", "rail": "us-ach", "class": "RuleSource", "name": "FedACH Services Dishonored Return Item Exception Fax Form Instructions, version 3.1, last updated 2024-04-22", "summary": "The Federal Reserve Banks' instructions for dishonoring a return by fax when electronic means fail: which fields of the returned item must be given, where each sits in the records, the return transaction code to use, and the field error codes for R69.", "publisher": "Federal Reserve Banks (FedACH Services)", "url": "https://www.frbservices.org/binaries/content/assets/crsocms/forms/ach/dishonored-instructions.pdf", "source_class": "public_primary", "kind": "pdf_document", "edition": "version 3.1, last updated 2024-04-22, 5 pages, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "Opened and read in full on 2026-09-19 for the file format drafting.", "confidence": "medium" }, "currency": { "effective_since": "2024-04-22", "effective_to": null, "effective_note": "Operator publication; it says it does not replace the Nacha rules. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "version 3.1, last updated 2024-04-22, 5 pages, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.format-dishonored-return-addenda", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.format-mandatory-required-optional-fields", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-transaction-codes", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.frb-fedach-fee-schedule-2026", "id": "src.frb-fedach-fee-schedule-2026", "rail": "us-ach", "class": "RuleSource", "name": "Federal Reserve Financial Services, FedACH Services 2026 Fee Schedule", "summary": "The Federal Reserve Banks' public 2026 FedACH fee schedule, including the SameDay Service surcharge and participation fee and the Nacha Same Day Entry Fee and credit the Reserve Banks collect and pay.", "publisher": "Federal Reserve Banks", "url": "https://www.frbservices.org/resources/fees/ach-2026", "source_class": "public_primary", "kind": "fee_schedule", "edition": "2026 fee schedule web page, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, opened and read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2026-01-01", "effective_to": null, "effective_note": "Created by a drafting session on 2026-09-19. A fee schedule for calendar year 2026 [Unverified: effective from 2026-01-01]; the 2027 schedule will replace it. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "2026 fee schedule web page, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.same-day-entry-fee", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.same-day-fedach-operator-charges", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.frb-fedach-origination-and-receipt", "id": "src.frb-fedach-origination-and-receipt", "rail": "us-ach", "class": "RuleSource", "name": "Federal Reserve Financial Services, FedACH Origination and Receipt", "summary": "The operator's public description of its core clearing service: scheduled file delivery, the sort options, and the file status, dollar confirmation and batch and item counts a bank can see on the files it has sent and received.", "publisher": "Federal Reserve Financial Services", "url": "https://www.frbservices.org/financial-services/ach/origination-receipt.html", "source_class": "public_primary", "kind": "service_description", "edition": "public page, undated, as read 2026-09-20", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The operator's own service page on frbservices.org, read 2026-09-20 for the file acknowledgement question in the OC-5 us-ach coverage gaps.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "A RuleSource describes one edition of one document. The page carries no date, so the read date stands for the edition; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "public page, undated, as read 2026-09-20", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.messages-the-operator-acknowledges-a-file-it-has-taken-in", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.frb-fedach-risk-origination-monitoring", "id": "src.frb-fedach-risk-origination-monitoring", "rail": "us-ach", "class": "RuleSource", "name": "Federal Reserve Financial Services, FedACH Risk Origination Monitoring Service", "summary": "The operator's public description of the service an originating bank uses to cap what its own routing numbers and company identifications may send, how the accumulation period is chosen, and what happens to a batch that goes over a cap.", "publisher": "Federal Reserve Financial Services", "url": "https://www.frbservices.org/financial-services/ach/risk/origination-monitoring.html", "source_class": "public_primary", "kind": "service_description", "edition": "public page, undated, as read 2026-09-20", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The operator's own service page on frbservices.org, read 2026-09-20 for the operator risk monitoring question in the OC-5 us-ach coverage gaps.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "A RuleSource describes one edition of one document. The page carries no date, so the read date stands for the edition; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "public page, undated, as read 2026-09-20", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.decision-points-what-a-bank-can-cap-in-operator-monitoring", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.frb-fedach-risk-rdfi-alert", "id": "src.frb-fedach-risk-rdfi-alert", "rail": "us-ach", "class": "RuleSource", "name": "Federal Reserve Financial Services, FedACH Risk RDFI Alert Service", "summary": "The operator's public description of the alerting service a receiving bank uses on its incoming files, the entry fields the alert criteria may be built from, who may subscribe, and when file, batch and entry alerts are sent.", "publisher": "Federal Reserve Financial Services", "url": "https://www.frbservices.org/financial-services/ach/risk/rdfi-file-alert.html", "source_class": "public_primary", "kind": "service_description", "edition": "public page, undated, as read 2026-09-20", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The operator's own service page on frbservices.org, read 2026-09-20 for the operator risk monitoring question in the OC-5 us-ach coverage gaps.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "A RuleSource describes one edition of one document. The page carries no date, so the read date stands for the edition; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "public page, undated, as read 2026-09-20", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.decision-points-what-a-bank-can-cap-in-operator-monitoring", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.frb-fedglobal-ach-payments", "id": "src.frb-fedglobal-ach-payments", "rail": "us-ach", "class": "RuleSource", "name": "Federal Reserve Financial Services, FedGlobal ACH Payments (service page)", "summary": "The Reserve Banks' page for their cross-border ACH service, with its foreign exchange options, the countries still served, and the notice that the service is being discontinued.", "publisher": "Federal Reserve Banks", "url": "https://www.frbservices.org/financial-services/ach/fedglobal", "source_class": "public_primary", "kind": "web_page", "edition": "web page as read 2026-09-19, carrying the 2025-11-25 discontinuation notice", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "Opened and read in full on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "The page states the service will be discontinued by year-end 2026 and takes no new sign-ups. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "web page as read 2026-09-19, carrying the 2025-11-25 discontinuation notice", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.iat-fedglobal-service-scope", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.iat-foreign-exchange-fields", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.frb-fedglobal-faqs", "id": "src.frb-fedglobal-faqs", "rail": "us-ach", "class": "RuleSource", "name": "Federal Reserve Financial Services, FedGlobal ACH Payments Frequently Asked Questions", "summary": "The Reserve Banks' public FAQ on FedGlobal ACH Payments: who may take part, deadlines, SEC code, settlement timing abroad, sign-up paperwork and the risks for an ODFI.", "publisher": "Federal Reserve Banks", "url": "https://www.frbservices.org/resources/financial-services/ach/faq/fedglobal.html", "source_class": "public_primary", "kind": "faq_page", "edition": "undated web page, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "Opened and read in full on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Undated; read beside the service page, which announces the service's end by year-end 2026. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "undated web page, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.iat-fedglobal-service-scope", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-foreign-exchange-fields", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-return-amount-may-differ", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-return-timeframes", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.frb-iat-faqs", "id": "src.frb-iat-faqs", "rail": "us-ach", "class": "RuleSource", "name": "Federal Reserve Financial Services, International ACH Transaction (IAT) Frequently Asked Questions", "summary": "The Reserve Banks' public IAT FAQ: why IAT was created, format points such as addenda limits and screening indicator fields, OFAC roles, and what FedACH and FedGlobal do with IAT items.", "publisher": "Federal Reserve Banks", "url": "https://www.frbservices.org/resources/financial-services/ach/faq/iat.html", "source_class": "public_primary", "kind": "faq_page", "edition": "undated web page, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "Opened and read in full on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Undated; parts of it were written before IAT took effect in 2009 and speak of it as new. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "undated web page, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:role.foreign-correspondent-bank", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-addenda-structure", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-fedglobal-service-scope", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-gateway-inbound-debit-limits", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-gateway-operator-defined", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-notifications-of-change", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-ofac-screening-duties", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-ofac-screening-indicators", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-one-code-consumer-and-business", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-party-information-every-entry", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-prenotes", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-rdfi-must-accept", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-replaced-cbr-and-pbr", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-reversal-best-effort", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-separate-file-option", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.participants-gateway-screening-does-not-move-the-duty", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.frb-operating-circular-4-2026-01-05", "id": "src.frb-operating-circular-4-2026-01-05", "rail": "us-ach", "class": "RuleSource", "name": "Federal Reserve Banks Operating Circular No. 4, Automated Clearing House Items, effective January 5, 2026", "summary": "The Reserve Banks' terms for handling ACH items through FedACH: settlement, finality, returns, liability and the banks' agreements with the Reserve Banks.", "publisher": "Federal Reserve Banks", "url": "https://www.frbservices.org/binaries/content/assets/crsocms/resources/rules-regulations/010526-operating-circular-4.pdf", "source_class": "authoritative_primary", "kind": "operating_circular", "edition": "edition effective 2026-01-05", "access": "open", "consulted_on": "2026-09-18", "relations": [], "basis": { "sources": "Described by the 2026-09 Orca Core migration from the citations and checks of us-ach:decision-points, us-ach:finality, us-ach:hours, us-ach:liability, us-ach:limits, us-ach:messages, us-ach:participants, us-ach:recall, us-ach:return and us-ach:settlement, which name it; the URL was confirmed to resolve on 2026-09-19 with a matching page title, and the document was not re-read for this record.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by the 2026-09 Orca Core migration from the us-ach rail fact citations. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "edition effective 2026-01-05", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:cal.federal-reserve-banks", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.decision-points-whether-to-dispute-a-return", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.dishonor-codes-exclude-iat", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.finality-ach-is-not-a-fedwire-funds-transfer-and", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.finality-no-recall-by-the-sender-once-the-file-has-gone", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.finality-second-layer-article-4a-and-only-for-some", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.finality-settlement-can-also-be-refused-before-it-happens", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.finality-settlement-can-be-unwound-the-next-morning", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.finality-the-moment-settlement-is-final-for-a-credit", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.hours-a-bank-closed-on-the-settlement-date", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.hours-a-day-off-the-holiday-list-is-still-a-banking-day", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.hours-a-deadline-stated-in-hours-runs-on-the-clock", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.hours-release-not-transmission-is-what-counts", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.hours-what-a-banking-day-is", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.iat-fedglobal-service-scope", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-no-dishonored-returns", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-return-amount-may-differ", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-return-timeframes", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-reversal-best-effort", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.liability-article-4a-credits-are-a-separate-regime", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.liability-banks-indemnify-the-operator-not-the-other-way", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.liability-how-damages-against-the-operator-are-measured", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.liability-settlement-risk-sits-with-the-reserve-banks", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.liability-the-operators-liability-and-what-it-is-not", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.liability-two-deadlines-that-quietly-destroy-claims", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.limits-eligibility-limits-not-just-dollar-limits", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.limits-funding-capacity-can-act-as-a-limit", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.limits-how-the-operator-sees-the-limit", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.limits-no-published-ceiling-on-non-same-day-entries", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.messages-a-suspected-duplicate-file-waits-for-the-sender", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.messages-the-operator-acknowledges-a-file-it-has-taken-in", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.messages-the-standard-entry-class-code", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.messages-traffic-that-moves-no-money", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.messages-who-defines-the-format", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.participants-a-correspondents-account-can-be-used-and-it", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.participants-agents-are-allowed-and-the-bank-still-owns-the", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.participants-receiving-is-an-agreement-too", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.participants-the-entry-condition-is-a-settlement-account", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.participants-who-counts-as-a-bank-for-fedach", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.recall-the-operator-has-its-own-cancellation-power", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.return-an-adjustment-path-exists-alongside-the-return", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.return-disputing-a-return-through-the-operator", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.return-how-a-return-settles", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.return-the-mechanism", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.settlement-credit-given-for-a-debit-is-not-the-same-as", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.settlement-effective-date-windows-are-bounded", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.settlement-prefunding-where-a-reserve-bank-requires-it", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.settlement-what-settlement-is", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.settlement-which-day-is-the-settlement-day", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.settlement-whose-obligation-it-is", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:txn.cor", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:txn.iat", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.frb-same-day-ach-faq", "id": "src.frb-same-day-ach-faq", "rail": "us-ach", "class": "RuleSource", "name": "Federal Reserve Financial Services, Same Day ACH Frequently Asked Questions", "summary": "The Federal Reserve Banks' public answers on FedACH same day processing, including how returns, NOCs, prenotifications and reversals are treated and charged.", "publisher": "Federal Reserve Banks", "url": "https://www.frbservices.org/resources/financial-services/ach/faq/same-day-ach.html", "source_class": "public_primary", "kind": "faq_page", "edition": "web page as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, opened and read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by a drafting session on 2026-09-19. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "web page as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.noc-same-day-and-fee", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.same-day-entry-fee", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.same-day-government-entries", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.same-day-ineligible-entry-settles-next-day", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.same-day-no-deadline-extensions", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.same-day-return-not-before-forward", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.same-day-returns-regardless-of-forward", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.same-day-risk-pended-batches", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.same-day-statement-identification", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:txn.cor", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.frb-savings-deposits-faq", "id": "src.frb-savings-deposits-faq", "rail": "us-ach", "class": "RuleSource", "name": "Federal Reserve Board, Savings Deposits Frequently Asked Questions", "summary": "The Board's public questions and answers on the April 2020 interim final rule that deleted the six per month transfer limit from the Regulation D definition of a savings deposit, and on what a depository institution may now allow.", "publisher": "Board of Governors of the Federal Reserve System", "url": "https://www.federalreserve.gov/supervisionreg/savings-deposits-frequently-asked-questions.htm", "source_class": "authoritative_primary", "kind": "faq", "edition": "public page, undated, as read 2026-09-20; describes the interim final rule announced 2020-04-24", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The Board's page on federalreserve.gov, reached through the Board's 2020-04-24 press release on the Regulation D interim final rule and read 2026-09-20.", "confidence": "medium" }, "currency": { "effective_since": "2020-04-24", "effective_to": null, "effective_note": "A RuleSource describes one edition of one document. The page is undated, so it carries the date of the interim final rule it explains; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "public page, undated, as read 2026-09-20", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.limits-ach-debits-to-a-savings-account", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.frbservices-holiday-schedules", "id": "src.frbservices-holiday-schedules", "rail": "us-ach", "class": "RuleSource", "name": "Federal Reserve Financial Services, Federal Reserve System Holiday Schedule", "summary": "The operator's published list of the days Reserve Banks and Branches are closed, the rule for a holiday falling on a Saturday or a Sunday, and a FedACH holiday schedule showing when processing ends before each holiday and resumes after it.", "publisher": "Federal Reserve Financial Services", "url": "https://www.frbservices.org/about/holiday-schedules", "source_class": "public_primary", "kind": "schedule", "edition": "the page as read 2026-09-20, listing the 2026 dates", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The operator's own holiday schedule page on frbservices.org, read 2026-09-20 for the banking day questions in the OC-5 us-ach coverage gaps.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "A RuleSource describes one edition of one document. The page is reissued each year and carries no edition date of its own, so the read date and the year it listed stand for the edition; the monthly watch dates it through consulted_on.", "source_edition": "the page as read 2026-09-20, listing the 2026 dates", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:cal.federal-reserve-banks", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.hours-a-day-off-the-holiday-list-is-still-a-banking-day", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.grand-valley-bank-prenote-waiting-period", "id": "src.grand-valley-bank-prenote-waiting-period", "rail": "us-ach", "class": "RuleSource", "name": "Grand Valley Bank, Prenotification Entries: Reduction in Waiting Period for Live Entries", "summary": "A bank's summary of the 2014 Nacha rule that shortened the wait after a prenote, with its effect on ODFIs and Originators.", "publisher": "Grand Valley Bank", "url": "https://www.grandvalleybank.com/assets/files/ip5QIqAu", "source_class": "secondary", "kind": "pdf_document", "edition": "undated summary naming the rule date 2014-09-19, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, opened and read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created while drafting the WEB account validation, micro-entry, prenote and authorization records on 2026-09-19. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "undated summary naming the rule date 2014-09-19, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.prenote-response-deadline-and-originator-action", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.prenote-wait-before-live-entries", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "id": "src.jefferson-bank-obligations-of-originators-2022-03", "rail": "us-ach", "class": "RuleSource", "name": "Jefferson Bank, Obligations of Originators, revised March 2022", "summary": "A bank's public guide for its ACH Originators, covering returns, dishonored and contested dishonored returns, Notifications of Change and refused NOCs, with the reason codes for each.", "publisher": "Jefferson Bank", "url": "https://www.jefferson-bank.com/uploadedfiles/includedcontent/business/obligations-of-originators.pdf?v=1D50A930C4ADA00", "source_class": "secondary", "kind": "bank_guide", "edition": "revised March 2022, per its page footers", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, opened and read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by a drafting session on 2026-09-19. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "revised March 2022, per its page footers", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:exc.contested-dishonored-return", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:exc.dishonored-return", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:exc.notification-of-change", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:exc.refused-notification-of-change", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.contest-window-2-banking-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.contested-dishonor-ends-the-network-dispute", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.dishonor-window-5-banking-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.noc-corrected-data-layout", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.noc-odfi-passes-it-on-within-2-banking-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.noc-originator-applies-the-change", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.noc-rdfi-warrants-the-corrected-data", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.noc-window-2-banking-days", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.modern-treasury-ach-return-code-reference", "id": "src.modern-treasury-ach-return-code-reference", "rail": "us-ach", "class": "RuleSource", "name": "ACH Return Codes (R01-R85), Modern Treasury", "summary": "A payments company's public reference to ACH return codes; validators checked us-ach code definitions and return windows against it.", "publisher": "Modern Treasury", "url": "https://www.moderntreasury.com/learn/ach-return-code-reference", "source_class": "secondary", "kind": "processor_reference", "edition": "public web page, undated, as read 2026-09-17", "access": "open", "consulted_on": "2026-09-17", "relations": [], "basis": { "sources": "Described from the corroboration entries of the us-ach reason codes that were checked against it (R14, R15); the document was not re-read for this record.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by the 2026-09 Orca Core migration from the us-ach reason code corroborations. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "public web page, undated, as read 2026-09-17", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.return-window-2-banking-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.modern-treasury-docs-ach-return-codes", "id": "src.modern-treasury-docs-ach-return-codes", "rail": "us-ach", "class": "RuleSource", "name": "Modern Treasury documentation, ACH Return Codes", "summary": "A payment platform's public developer documentation listing ACH return codes and the NOC change codes it handles.", "publisher": "Modern Treasury", "url": "https://docs.moderntreasury.com/payments/docs/ach-return-codes", "source_class": "secondary", "kind": "web_page", "edition": "web page as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, opened and read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by a drafting session on 2026-09-19. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "web page as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:src.moov-ach-addenda99-dishonored-source", "id": "src.moov-ach-addenda99-dishonored-source", "rail": "us-ach", "class": "RuleSource", "name": "moov-io/ach source file addenda99_dishonored_return.go", "summary": "Source code of an open source ACH library for the addenda record of a dishonored return: the fields it holds, where the library cuts each one, and the dishonor codes it accepts.", "publisher": "moov-io (GitHub)", "url": "https://github.com/moov-io/ach/blob/master/addenda99_dishonored_return.go", "source_class": "secondary", "kind": "source_code", "edition": "master branch as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "Opened and read in full on 2026-09-19 for the file format drafting.", "confidence": "low" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Code, not an authority; issue 1537 of the same project records the maintainer checking the field cut points against the Nacha standard. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "master branch as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.format-dishonored-return-addenda", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.moov-ach-file-structure", "id": "src.moov-ach-file-structure", "rail": "us-ach", "class": "RuleSource", "name": "moov-io/ach documentation, ACH File Structure", "summary": "Annotated record formats published with an open source ACH library: the record sequence, fill conventions, mandatory, required and optional fields, and entry and addenda layouts for each SEC code including CIE, CTX, ENR, MTE and IAT.", "publisher": "Moov Financial (moov-io open source project)", "url": "https://moov-io.github.io/ach/file-structure/", "source_class": "secondary", "kind": "web_page", "edition": "documentation page as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "Opened and read in full on 2026-09-19 for the file format drafting.", "confidence": "low" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Documentation of an open source library, not an authority; parts of it follow bank originator guides. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "documentation page as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.format-addenda-indicator-and-linking", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-batch-control-totals", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-batch-header-holds-what-entries-share", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-blocking-and-padding", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-cie-mte-name-and-identification", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.format-ctx-return", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.format-field-fill-conventions", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-file-header-and-control", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-mandatory-required-optional-fields", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.format-return-entry-construction", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.moov-ach-issue-1462", "id": "src.moov-ach-issue-1462", "rail": "us-ach", "class": "RuleSource", "name": "moov-io/ach GitHub issue 1462, validation of the Foreign Exchange Reference Indicator on incoming IAT", "summary": "A public issue on an open source ACH library, opened 2024-08-12, reporting an incoming IAT batch with a blank Foreign Exchange Reference Indicator that the ACH Operator did not reject, and the library's resulting change.", "publisher": "moov-io (GitHub)", "url": "https://github.com/moov-io/ach/issues/1462", "source_class": "secondary", "kind": "issue_thread", "edition": "issue opened 2024-08-12 with maintainer replies, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "Opened and read, with its comments, on 2026-09-19.", "confidence": "low" }, "currency": { "effective_since": "2024-08-12", "effective_to": null, "effective_note": "Practitioner report, not an authority; it shows observed operator behaviour only. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "issue opened 2024-08-12 with maintainer replies, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.iat-foreign-exchange-fields", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.moov-ach-issue-1501", "id": "src.moov-ach-issue-1501", "rail": "us-ach", "class": "RuleSource", "name": "moov-io/ach GitHub issue 1501, cannot create a return file for SEC code CTX", "summary": "A public issue on an open source ACH library, opened 2024-11-07, where a CTX return with a return addenda was refused; the maintainer traced it to CTX entries not having exactly the same fields as other entry detail records.", "publisher": "moov-io (GitHub)", "url": "https://github.com/moov-io/ach/issues/1501", "source_class": "secondary", "kind": "issue_thread", "edition": "issue opened 2024-11-07 with maintainer replies to 2024-11-08, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "Opened and read in full on 2026-09-19 for the file format drafting.", "confidence": "low" }, "currency": { "effective_since": "2024-11-07", "effective_to": null, "effective_note": "Practitioner report, not an authority. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "issue opened 2024-11-07 with maintainer replies to 2024-11-08, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.format-ctx-return", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.moov-ach-issue-151", "id": "src.moov-ach-issue-151", "rail": "us-ach", "class": "RuleSource", "name": "moov-io/ach GitHub issue 151, convert a batch to a batch of returns", "summary": "A public design issue on an open source ACH library, opened 2017-11-21, on building a return batch from an original batch, with practitioner comments on which header fields change and which records are copied.", "publisher": "moov-io (GitHub)", "url": "https://github.com/moov-io/ach/issues/151", "source_class": "secondary", "kind": "issue_thread", "edition": "issue opened 2017-11-21 with comments to 2018-12-11, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "Opened and read in full on 2026-09-19 for the file format drafting.", "confidence": "low" }, "currency": { "effective_since": "2017-11-21", "effective_to": null, "effective_note": "Practitioner discussion, not an authority; one comment quotes the Nacha rules, which Orca does not reproduce. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "issue opened 2017-11-21 with comments to 2018-12-11, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.format-return-entry-construction", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.moov-ach-issue-1672", "id": "src.moov-ach-issue-1672", "rail": "us-ach", "class": "RuleSource", "name": "moov-io/ach GitHub issue 1672, ENR batch validation rejects return transaction codes 21 and 31", "summary": "A public issue on an open source ACH library, opened 2025-09-29, reporting that ENR batches refused the return transaction codes 21 and 31; the maintainer published a fix on 2025-10-31.", "publisher": "moov-io (GitHub)", "url": "https://github.com/moov-io/ach/issues/1672", "source_class": "secondary", "kind": "issue_thread", "edition": "issue opened 2025-09-29 with maintainer reply of 2025-10-31, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "Opened and read in full on 2026-09-19 for the file format drafting.", "confidence": "low" }, "currency": { "effective_since": "2025-09-29", "effective_to": null, "effective_note": "Practitioner report, not an authority; its business scenario has the RDFI returning an ENR, which reverses who sends an ENR under the Green Book. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "issue opened 2025-09-29 with maintainer reply of 2025-10-31, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.format-enr-entry-codes", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.moov-ach-issue-1766", "id": "src.moov-ach-issue-1766", "rail": "us-ach", "class": "RuleSource", "name": "moov-io/ach GitHub issue 1766, Individual Identification Number and Individual Name flipped for CIE and MTE", "summary": "A public bug report on an open source ACH library, opened 2026-04-01, reporting that the library read the name and identification number of CIE and MTE entries in each other's places; the maintainer opened a fix.", "publisher": "moov-io (GitHub)", "url": "https://github.com/moov-io/ach/issues/1766", "source_class": "secondary", "kind": "issue_thread", "edition": "issue opened 2026-04-01 with replies to 2026-04-02, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "Opened and read in full on 2026-09-19 for the file format drafting.", "confidence": "low" }, "currency": { "effective_since": "2026-04-01", "effective_to": null, "effective_note": "Practitioner report, not an authority. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "issue opened 2026-04-01 with replies to 2026-04-02, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.format-cie-mte-name-and-identification", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.moov-ach-returns-docs", "id": "src.moov-ach-returns-docs", "rail": "us-ach", "class": "RuleSource", "name": "moov-io/ach documentation, Returns", "summary": "Documentation of an open source ACH library on creating a return: a return addenda record is attached to the entry, carrying the return code and the original trace number, and the entry gets a new trace number.", "publisher": "Moov Financial (moov-io open source project)", "url": "https://moov-io.github.io/ach/returns/", "source_class": "secondary", "kind": "web_page", "edition": "documentation page as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "Opened and read in full on 2026-09-19 for the file format drafting.", "confidence": "low" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Documentation of an open source library, not an authority. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "documentation page as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.format-return-entry-construction", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-trace-number-assignment", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.nacha-abcs-of-ach", "id": "src.nacha-abcs-of-ach", "rail": "us-ach", "class": "RuleSource", "name": "Nacha, The ABCs of ACH", "summary": "Nacha's public overview of the network: hours, settlements per day, Same Day ACH limits and common industry practices.", "publisher": "Nacha", "url": "https://www.nacha.org/content/abcs-ach", "source_class": "public_primary", "kind": "explainer", "edition": "public page, undated, as read 2026-09-17", "access": "open", "consulted_on": "2026-09-17", "relations": [], "basis": { "sources": "Described by the 2026-09 Orca Core migration from the citations and checks of us-ach:decision-points, us-ach:hours, us-ach:limits and us-ach:settlement, which name it; the URL was confirmed to resolve on 2026-09-19 with a matching page title, and the document was not re-read for this record.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by the 2026-09 Orca Core migration from the us-ach rail fact citations. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "public page, undated, as read 2026-09-17", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.decision-points-whether-funds-appear-before-settlement", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.hours-how-long-the-network-is-open", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.hours-industry-practice-around-weekends", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.limits-the-ceiling-that-is-coming", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.settlement-the-settlement-asset-and-its-hours", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.nacha-ach-developer-guide-file-details", "id": "src.nacha-ach-developer-guide-file-details", "rail": "us-ach", "class": "RuleSource", "name": "Nacha, ACH Guide for Developers: ACH File Details", "summary": "Nacha's free web guide page giving the file header and control, batch header and control, and PPD, CCD, WEB and TEL entry and addenda layouts, with notes on each field, and a table of common SEC codes.", "publisher": "Nacha", "url": "https://achdevguide.nacha.org/ach-file-details", "source_class": "public_primary", "kind": "web_page", "edition": "web page as read 2026-09-19 (page footer dated 2026)", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "Opened and read in full on 2026-09-19 for the file format drafting.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Public developer guide published by Nacha; it covers PPD, CCD, WEB and TEL entries only and points to Appendix Three of the rules for the full layouts. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "web page as read 2026-09-19 (page footer dated 2026)", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.format-addenda-indicator-and-linking", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.format-batch-control-totals", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.format-batch-header-holds-what-entries-share", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.format-blocking-and-padding", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-cie-mte-name-and-identification", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-file-header-and-control", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.format-trace-number-assignment", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.nacha-ach-developer-guide-file-overview", "id": "src.nacha-ach-developer-guide-file-overview", "rail": "us-ach", "class": "RuleSource", "name": "Nacha, ACH Guide for Developers: ACH File Overview", "summary": "Nacha's free web guide for developers building ACH files: how records nest into batches and a file, the header and control pairs, blocking and padding, balanced and unbalanced files, field fill conventions, and the common transaction and service class codes.", "publisher": "Nacha", "url": "https://achdevguide.nacha.org/ach-file-overview", "source_class": "public_primary", "kind": "web_page", "edition": "web page as read 2026-09-19 (page footer dated 2026)", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "Opened and read in full on 2026-09-19 for the file format drafting.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Public developer guide published by Nacha; it is not the Nacha Operating Rules and says the full layouts are in Appendix Three of the rules. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "web page as read 2026-09-19 (page footer dated 2026)", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.format-balanced-and-unbalanced-files", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.format-batch-header-holds-what-entries-share", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-blocking-and-padding", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.format-field-fill-conventions", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.format-file-header-and-control", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-record-line-ending", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.format-trace-number-assignment", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.format-transaction-codes", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.nacha-ach-volume-statistics", "id": "src.nacha-ach-volume-statistics", "rail": "us-ach", "class": "RuleSource", "name": "Nacha, ACH Network Volume and Value Statistics", "summary": "Nacha's published ACH volume and value figures.", "publisher": "Nacha", "url": "https://www.nacha.org/content/ach-network-volume-and-value-statistics", "source_class": "public_primary", "kind": "statistics", "edition": "public page with figures for full year 2025, as read 2026-09-17", "access": "open", "consulted_on": "2026-09-17", "relations": [], "basis": { "sources": "Described by the 2026-09 Orca Core migration from the citations and checks of us-ach:participants, which name it; the URL was confirmed to resolve on 2026-09-19 with a matching page title, and the document was not re-read for this record.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by the 2026-09 Orca Core migration from the us-ach rail fact citations. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "public page with figures for full year 2025, as read 2026-09-17", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.participants-scale-for-context", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.nacha-company-entry-descriptions", "id": "src.nacha-company-entry-descriptions", "rail": "us-ach", "class": "RuleSource", "name": "Nacha, Risk Management Topics, Company Entry Descriptions, effective 2026-03-20", "summary": "Nacha's public page on the standard PAYROLL and PURCHASE company entry descriptions.", "publisher": "Nacha", "url": "https://www.nacha.org/rules/risk-management-topics-company-entry-descriptions", "source_class": "public_primary", "kind": "rule_change_page", "edition": "public rule page for the rule effective 2026-03-20, as read 2026-09-17", "access": "open", "consulted_on": "2026-09-17", "relations": [], "basis": { "sources": "Described by the 2026-09 Orca Core migration from the citations and checks of us-ach:decision-points and us-ach:messages, which name it; the URL was confirmed to resolve on 2026-09-19 with a matching page title, and the document was not re-read for this record.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by the 2026-09 Orca Core migration from the us-ach rail fact citations. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "public rule page for the rule effective 2026-03-20, as read 2026-09-17", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.decision-points-whether-a-description-is-true", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.messages-the-description-field-is-becoming-meaningful", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.nacha-consumer-faqs-ach-payments", "id": "src.nacha-consumer-faqs-ach-payments", "rail": "us-ach", "class": "RuleSource", "name": "Nacha, Consumer FAQs on ACH Payments", "summary": "Nacha's public answers for account holders: what Nacha itself does, whether it can look up an individual payment, who to approach about a missing direct deposit, and what to do about a debit the account holder does not recognise.", "publisher": "Nacha", "url": "https://www.nacha.org/content/consumer-faqs-ach-payments", "source_class": "public_primary", "kind": "faq", "edition": "public page, undated, as read 2026-09-20", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "Nacha's consumer FAQ page on nacha.org, read 2026-09-20 for the consumer handling questions in the OC-5 us-ach coverage gaps.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "A RuleSource describes one edition of one document. The page carries no date, so the read date stands for the edition; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "public page, undated, as read 2026-09-20", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.participants-who-an-account-holder-asks-about-a-payment", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.nacha-currently-accepted-characters", "id": "src.nacha-currently-accepted-characters", "rail": "us-ach", "class": "RuleSource", "name": "Nacha, Currently Accepted Characters in the ACH Network, effective January 1, 2027", "summary": "Nacha's public page on the characters each ACH Operator accepts and the 94 byte record line.", "publisher": "Nacha", "url": "https://www.nacha.org/rules/currently-accepted-characters-ach-network", "source_class": "public_primary", "kind": "rule_change_page", "edition": "public rule page for the rule effective 2027-01-01, as read 2026-09-17", "access": "open", "consulted_on": "2026-09-18", "relations": [], "basis": { "sources": "Described by the 2026-09 Orca Core migration from the citations and checks of us-ach:messages, which name it; the URL was confirmed to resolve on 2026-09-19 with a matching page title, and the document was not re-read for this record.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by the 2026-09 Orca Core migration from the us-ach rail fact citations. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "public rule page for the rule effective 2027-01-01, as read 2026-09-17", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.messages-character-handling-is-not-uniform-between", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.messages-the-record-line", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.messages-the-record-types-a-payment-uses", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.nacha-definition-of-iat-entries", "id": "src.nacha-definition-of-iat-entries", "rail": "us-ach", "class": "RuleSource", "name": "Nacha, Definition of IAT Entries (new rule page)", "summary": "Nacha's public page for the rule that replaced the IAT definition, effective 2026-09-18, with the sections it amends and its expected impact.", "publisher": "Nacha", "url": "https://www.nacha.org/rules/definition-iat-entries", "source_class": "public_primary", "kind": "rule_change_page", "edition": "public rule page, effective date 2026-09-18, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "Opened and read in full on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2026-09-18", "effective_to": null, "effective_note": "Describes a rule in force from 2026-09-18 (Article Eight, Section 8.55 and related sections). A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "public rule page, effective date 2026-09-18, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.iat-definition", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:txn.iat", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.nacha-differentiating-unauthorized-return-reasons", "id": "src.nacha-differentiating-unauthorized-return-reasons", "rail": "us-ach", "class": "RuleSource", "name": "Differentiating Unauthorized Return Reasons (Nacha)", "summary": "Nacha's public explanation of the 2020 rule that narrowed R10, repurposed R11, and set how both count toward the unauthorized return rate.", "publisher": "Nacha", "url": "https://www.nacha.org/rules/differentiating-unauthorized-return-reasons", "source_class": "public_primary", "kind": "rule_change_page", "edition": "public rule page describing the change effective 2020-04-01, as read 2026-09-17", "access": "open", "consulted_on": "2026-09-17", "relations": [], "basis": { "sources": "Described from the corroboration entries of the us-ach reason codes that were checked against it (R10, R11); the document was not re-read for this record.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by the 2026-09 Orca Core migration from the us-ach reason code corroborations. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "public rule page describing the change effective 2020-04-01, as read 2026-09-17", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.r11-corrected-entry", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.return-window-60-calendar-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.unauthorized-return-rate-threshold", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.written-statement-of-unauthorized-debit", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.nacha-expanding-same-day-ach", "id": "src.nacha-expanding-same-day-ach", "rail": "us-ach", "class": "RuleSource", "name": "Nacha, Expanding Same Day ACH, rule effective 2021-03-19", "summary": "Nacha's public rule page for the third Same Day ACH window: its submission deadline, 18:00 Eastern settlement, funds availability, eligibility of returns and NOCs, and the optional SD1800 indicator.", "publisher": "Nacha", "url": "https://www.nacha.org/rules/expanding-same-day-ach", "source_class": "public_primary", "kind": "rule_change_page", "edition": "public rule page for the rule effective 2021-03-19, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, opened and read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2021-03-19", "effective_to": null, "effective_note": "Created by a drafting session on 2026-09-19. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "public rule page for the rule effective 2021-03-19, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.hours-same-day-credit-funds-availability", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.same-day-ineligible-entry-settles-next-day", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.same-day-returns-regardless-of-forward", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.nacha-fraud-monitoring-phase-1", "id": "src.nacha-fraud-monitoring-phase-1", "rail": "us-ach", "class": "RuleSource", "name": "Nacha, Risk Management Topics, Fraud Monitoring Phase 1, effective 2026-03-20", "summary": "Nacha's public page on the first phase of risk based fraud monitoring duties, for ODFIs and the largest originators, service providers and RDFIs.", "publisher": "Nacha", "url": "https://www.nacha.org/rules/risk-management-topics-fraud-monitoring-phase-1", "source_class": "public_primary", "kind": "rule_change_page", "edition": "public rule page for the phase effective 2026-03-20, as read 2026-09-17", "access": "open", "consulted_on": "2026-09-17", "relations": [], "basis": { "sources": "Described by the 2026-09 Orca Core migration from the citations and checks of us-ach:decision-points, us-ach:liability and us-ach:participants, which name it; the URL was confirmed to resolve on 2026-09-19 with a matching page title, and the document was not re-read for this record.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by the 2026-09 Orca Core migration from the us-ach rail fact citations. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "public rule page for the phase effective 2026-03-20, as read 2026-09-17", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.decision-points-where-to-set-the-fraud-thresholds", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.liability-fraud-duties-are-monitoring-duties-not-a-loss", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.participants-new-duties-reach-originators-and-service", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.nacha-fraud-monitoring-phase-2", "id": "src.nacha-fraud-monitoring-phase-2", "rail": "us-ach", "class": "RuleSource", "name": "Nacha, Risk Management Topics, Fraud Monitoring Phase 2, effective 2026-06-19", "summary": "Nacha's public page on the second phase of fraud monitoring duties, for the remaining participants.", "publisher": "Nacha", "url": "https://www.nacha.org/rules/risk-management-topics-fraud-monitoring-phase-2", "source_class": "public_primary", "kind": "rule_change_page", "edition": "public rule page for the phase effective 2026-06-19, as read 2026-09-17", "access": "open", "consulted_on": "2026-09-17", "relations": [], "basis": { "sources": "Described by the 2026-09 Orca Core migration from the citations and checks of us-ach:decision-points, us-ach:liability and us-ach:participants, which name it; the URL was confirmed to resolve on 2026-09-19 with a matching page title, and the document was not re-read for this record.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by the 2026-09 Orca Core migration from the us-ach rail fact citations. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "public rule page for the phase effective 2026-06-19, as read 2026-09-17", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.decision-points-where-to-set-the-fraud-thresholds", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.liability-fraud-duties-are-monitoring-duties-not-a-loss", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.participants-new-duties-reach-originators-and-service", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.nacha-funds-availability-non-same-day-credits", "id": "src.nacha-funds-availability-non-same-day-credits", "rail": "us-ach", "class": "RuleSource", "name": "Nacha, Funds Availability Requirements for Non-Same Day Credit Entries, effective September 18, 2026", "summary": "Nacha's public page on the 09:00 local availability duty for next day and two day credits.", "publisher": "Nacha", "url": "https://www.nacha.org/rules/funds-availability-requirements-non-same-day-credit-entries", "source_class": "public_primary", "kind": "rule_change_page", "edition": "public rule page for the rule effective 2026-09-18, as read 2026-09-17", "access": "open", "consulted_on": "2026-09-18", "relations": [], "basis": { "sources": "Described by the 2026-09 Orca Core migration from the citations and checks of us-ach:hours, which name it; the URL was confirmed to resolve on 2026-09-19 with a matching page title, and the document was not re-read for this record.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by the 2026-09 Orca Core migration from the us-ach rail fact citations. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "public rule page for the rule effective 2026-09-18, as read 2026-09-17", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.hours-when-the-receiver-can-use-the-money", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.nacha-how-ach-payments-work", "id": "src.nacha-how-ach-payments-work", "rail": "us-ach", "class": "RuleSource", "name": "Nacha, How ACH Payments Work", "summary": "Nacha's public explanation of the five roles in an ACH payment and the two ACH Operators.", "publisher": "Nacha", "url": "https://www.nacha.org/content/how-ach-payments-work", "source_class": "public_primary", "kind": "explainer", "edition": "public page, undated, as read 2026-09-17", "access": "open", "consulted_on": "2026-09-18", "relations": [], "basis": { "sources": "Described by the 2026-09 Orca Core migration from the citations and checks of us-ach:participants, which name it; the URL was confirmed to resolve on 2026-09-19 with a matching page title, and the document was not re-read for this record.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by the 2026-09 Orca Core migration from the us-ach rail fact citations. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "public page, undated, as read 2026-09-17", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.participants-the-five-roles", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.participants-there-are-two-operators-not-one", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.nacha-iat-contact-registry-rule", "id": "src.nacha-iat-contact-registry-rule", "rail": "us-ach", "class": "RuleSource", "name": "Nacha, Registration of IAT Contacts in the ACH Contact Registry (new rule page)", "summary": "Nacha's public page for the rule, effective 2027-01-01, that makes an IAT handling contact a required entry in the ACH Contact Registry.", "publisher": "Nacha", "url": "https://www.nacha.org/rules/registration-iat-contacts-ach-contact-registry", "source_class": "public_primary", "kind": "rule_change_page", "edition": "public rule page, effective date 2027-01-01, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "Opened and read in full on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2027-01-01", "effective_to": null, "effective_note": "Describes a rule that takes effect 2027-01-01 (Section 1.14). A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "public rule page, effective date 2027-01-01, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.iat-contact-registry-from-2027", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.nacha-iat-executive-summary-2008-07-31", "id": "src.nacha-iat-executive-summary-2008-07-31", "rail": "us-ach", "class": "RuleSource", "name": "Nacha, International ACH Transactions Executive Summary, July 31, 2008", "summary": "Nacha's four page summary of the rule that created IAT: why it was made, the 2009 definition, Gateway Operator roles, and the format's addenda and screening indicators.", "publisher": "Nacha", "url": "https://www.nacha.org/system/files/2023-04/IAT-Executive-Summary-7-31-2008.pdf", "source_class": "public_primary", "kind": "pdf_document", "edition": "dated 2008-07-31, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "Opened and read in full on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2008-07-31", "effective_to": null, "effective_note": "Historical summary of the IAT rule effective 2009-09-18; its definition section describes the definition that the 2026-09-18 rule replaced. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "dated 2008-07-31, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:role.gateway", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-addenda-structure", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-definition", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-gateway-inbound-debit-limits", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.iat-gateway-operator-defined", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-ofac-screening-duties", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-ofac-screening-indicators", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-party-information-every-entry", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-replaced-cbr-and-pbr", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.iat-return-addenda", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.nacha-iat-faqs-2021-03-09", "id": "src.nacha-iat-faqs-2021-03-09", "rail": "us-ach", "class": "RuleSource", "name": "Nacha, International ACH Transactions (IAT) Frequently Asked Questions, updated March 9, 2021", "summary": "Nacha's longer IAT FAQ document, 109 numbered questions covering general points, origination, receipt, returns, formatting, addenda, exceptions and OFAC compliance.", "publisher": "Nacha", "url": "https://www.nacha.org/system/files/2021-03/IAT-Frequently-Asked-Questions-FAQs-3-9-21.pdf", "source_class": "public_primary", "kind": "pdf_document", "edition": "revised 2021-03-09, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "Opened and read in full on 2026-09-19 for the IAT drafting pass; cited by question number.", "confidence": "medium" }, "currency": { "effective_since": "2021-03-09", "effective_to": null, "effective_note": "Revised 2021-03-09; predates the 2026-09-18 IAT definition. Some answers name the Federal Reserve's service as FedACH International, the older name of FedGlobal. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "revised 2021-03-09, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:role.foreign-correspondent-bank", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.decision-points-what-a-false-positive-is-on-a-sanctions-screen", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.iat-addenda-structure", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.iat-foreign-exchange-fields", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-gateway-agreement-with-odfi", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.iat-gateway-only-return-codes", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.iat-gateway-operator-defined", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-no-dishonored-returns", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.iat-notifications-of-change", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.iat-ofac-hold-before-posting", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.iat-ofac-screening-duties", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-ofac-screening-indicators", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.iat-one-code-consumer-and-business", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-party-information-every-entry", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.iat-prenotes", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.iat-rdfi-must-accept", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.iat-replaced-cbr-and-pbr", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-return-addenda", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.iat-return-amount-may-differ", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.iat-return-timeframes", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.iat-reversal-best-effort", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.iat-us-jurisdiction-is-domestic", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.messages-the-travel-rule-threshold-and-what-an-iat-carries", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.participants-gateway-screening-does-not-move-the-duty", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.nacha-iat-faqs-web", "id": "src.nacha-iat-faqs-web", "rail": "us-ach", "class": "RuleSource", "name": "Nacha, International ACH Transactions FAQs (web page)", "summary": "Nacha's public question and answer page on IAT, grouped into general, origination, receipt and returns, and OFAC compliance questions.", "publisher": "Nacha", "url": "https://www.nacha.org/content/international-ach-transactions-faqs", "source_class": "public_primary", "kind": "faq_page", "edition": "web page dated 2021-05-19, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "Opened and read in full on 2026-09-19 for the IAT drafting pass.", "confidence": "medium" }, "currency": { "effective_since": "2021-05-19", "effective_to": null, "effective_note": "Page dated 2021-05-19; it predates the IAT definition that took effect 2026-09-18, and its answers were not updated for it. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "web page dated 2021-05-19, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:role.foreign-correspondent-bank", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:role.gateway", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.iat-definition", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-gateway-agreement-with-odfi", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-gateway-only-return-codes", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-gateway-operator-defined", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.iat-no-dishonored-returns", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-notifications-of-change", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-ofac-hold-before-posting", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-ofac-screening-duties", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.iat-one-code-consumer-and-business", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.iat-party-information-every-entry", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-prenotes", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-rdfi-must-accept", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-return-amount-may-differ", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-return-timeframes", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-reversal-best-effort", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-us-jurisdiction-is-domestic", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:txn.iat", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.nacha-iat-rules-changes-2026-06-12", "id": "src.nacha-iat-rules-changes-2026-06-12", "rail": "us-ach", "class": "RuleSource", "name": "Nacha, Prepare Today for Upcoming IAT Rules Changes (blog post, June 12, 2026)", "summary": "Nacha news post summarising the dated IAT rule changes: IAT contacts in the ACH Contact Registry from 2027-01-01, a date of birth field from 2027-03-19, and R90 from 2028-03-17.", "publisher": "Nacha", "url": "https://www.nacha.org/news/prepare-today-upcoming-iat-rules-changes", "source_class": "public_primary", "kind": "news_post", "edition": "posted 2026-06-12, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "Opened and read in full on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2026-06-12", "effective_to": null, "effective_note": "News post, not rule text. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "posted 2026-06-12, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.iat-contact-registry-from-2027", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-date-of-birth-field-from-2027", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.iat-ofac-hold-before-posting", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.nacha-importance-compliant-ach-authorizations", "id": "src.nacha-importance-compliant-ach-authorizations", "rail": "us-ach", "class": "RuleSource", "name": "Nacha, The Importance of Compliant ACH Authorizations", "summary": "A Nacha article on what a compliant debit authorization needs and what non-compliance costs.", "publisher": "Nacha", "url": "https://www.nacha.org/news/importance-compliant-ach-authorizations", "source_class": "public_primary", "kind": "news_article", "edition": "article published 2025-11-03, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The article itself, opened and read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2025-11-03", "effective_to": null, "effective_note": "Created while drafting the WEB account validation, micro-entry, prenote and authorization records on 2026-09-19. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "article published 2025-11-03, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.authorization-general-requirements", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.nacha-limitation-on-warranty-claims", "id": "src.nacha-limitation-on-warranty-claims", "rail": "us-ach", "class": "RuleSource", "name": "Nacha, Limitation on Warranty Claims, rule effective 2021-06-30", "summary": "Nacha's public page on the time limits for an RDFI's claim against the ODFI's authorization warranty.", "publisher": "Nacha", "url": "https://www.nacha.org/rules/limitation-warranty-claims", "source_class": "public_primary", "kind": "rule_change_page", "edition": "public rule page for the rule effective 2021-06-30, as read 2026-09-17", "access": "open", "consulted_on": "2026-09-18", "relations": [], "basis": { "sources": "Described by the 2026-09 Orca Core migration from the citations and checks of us-ach:consumer-law, us-ach:liability and us-ach:refund, which name it; the URL was confirmed to resolve on 2026-09-19 with a matching page title, and the document was not re-read for this record.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by the 2026-09 Orca Core migration from the us-ach rail fact citations. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "public rule page for the rule effective 2021-06-30, as read 2026-09-17", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.liability-the-warranty-that-carries-loss-back-to-the", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.refund-why-95-days-and-not-60", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.nacha-micro-entries-phase-1", "id": "src.nacha-micro-entries-phase-1", "rail": "us-ach", "class": "RuleSource", "name": "Nacha, Micro-Entries (Phase 1)", "summary": "Nacha's public rule page, with FAQs, defining micro-entries and their format; the page is marked archived.", "publisher": "Nacha", "url": "https://www.nacha.org/micro-entries", "source_class": "public_primary", "kind": "rule_change_page", "edition": "public rule page with FAQs, rule effective 2022-09-16, marked archived, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The page itself, opened and read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2022-09-16", "effective_to": null, "effective_note": "Created while drafting the WEB account validation, micro-entry, prenote and authorization records on 2026-09-19. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "public rule page with FAQs, rule effective 2022-09-16, marked archived, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.micro-entries-amounts-and-timing", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.micro-entries-definition-and-labels", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.micro-entries-receiver-confirmation", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:txn.micro-entry", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.nacha-micro-entries-phase-2", "id": "src.nacha-micro-entries-phase-2", "rail": "us-ach", "class": "RuleSource", "name": "Nacha, Micro-Entries (Phase 2)", "summary": "Nacha's public rule page for the second phase of the micro-entry rule, the fraud detection duty.", "publisher": "Nacha", "url": "https://www.nacha.org/rules/micro-entries-phase-2", "source_class": "public_primary", "kind": "rule_change_page", "edition": "public rule page, rule effective 2023-03-17, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The page itself, opened and read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2023-03-17", "effective_to": null, "effective_note": "Created while drafting the WEB account validation, micro-entry, prenote and authorization records on 2026-09-19. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "public rule page, rule effective 2023-03-17, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.micro-entries-fraud-monitoring", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.nacha-minor-topics-funds-availability-exceptions", "id": "src.nacha-minor-topics-funds-availability-exceptions", "rail": "us-ach", "class": "RuleSource", "name": "Nacha, Minor Topics Rule Change, Funds Availability Exceptions for non-Same Day Credit Entries, effective 2026-09-18", "summary": "Nacha's public page on the availability exception for RDFIs east of Atlantic time and west of the International Date Line.", "publisher": "Nacha", "url": "https://www.nacha.org/rules/minor-topics-rule-change-funds-availability-exceptions-non-same-day-credit-entries-0", "source_class": "public_primary", "kind": "rule_change_page", "edition": "public rule page for the rule effective 2026-09-18, as read 2026-09-17", "access": "open", "consulted_on": "2026-09-17", "relations": [], "basis": { "sources": "Described by the 2026-09 Orca Core migration from the citations and checks of us-ach:hours, which name it; the URL was confirmed to resolve on 2026-09-19 with a matching page title, and the document was not re-read for this record.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by the 2026-09 Orca Core migration from the us-ach rail fact citations. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "public rule page for the rule effective 2026-09-18, as read 2026-09-17", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.hours-one-geographic-exception-to-that-availability", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.nacha-ops-bulletin-2-2014-third-party-senders", "id": "src.nacha-ops-bulletin-2-2014-third-party-senders", "rail": "us-ach", "class": "RuleSource", "name": "Nacha, ACH Operations Bulletin #2-2014, ACH Transactions Involving Third-Party Senders and Other Payment Intermediaries, 2014-12-30", "summary": "Nacha's guidance on telling Originators, Third-Party Senders and Third-Party Service Providers apart, worked through payroll, tuition, dues, rental and e-wallet scenarios.", "publisher": "Nacha", "url": "https://www.nacha.org/system/files/2023-08/ACH-Operations-Bulletin-2-2014.pdf", "source_class": "public_primary", "kind": "operations_bulletin", "edition": "bulletin dated 2014-12-30, citing the 2015 Nacha Operating Rules, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, opened and read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2014-12-30", "effective_to": null, "effective_note": "Created by a drafting session on 2026-09-19. The bulletin predates the Nested Third-Party Sender definition of 2022-09-30 and cites 2015 section numbers. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "bulletin dated 2014-12-30, citing the 2015 Nacha Operating Rules, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:role.third-party-sender", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:role.third-party-service-provider", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.odfi-oversight-of-third-party-senders", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.tps-company-name-and-identification", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.tps-payment-facilitators", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.tps-which-role-an-intermediary-plays", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.nacha-ops-bulletin-2-2024-individual-name", "id": "src.nacha-ops-bulletin-2-2024-individual-name", "rail": "us-ach", "class": "RuleSource", "name": "Nacha, ACH Operations Bulletin 2-2024, Voluntary Formatting Standard for the Individual Name Field", "summary": "Nacha's public bulletin recommending a format for the individual name field, which restates that an RDFI may post an entry on the account number alone and that name matching is not required of a receiving institution.", "publisher": "Nacha", "url": "https://www.nacha.org/news/ach-operations-bulletin-2-2024-voluntary-formatting-standard-individual-name-field", "source_class": "public_primary", "kind": "operations_bulletin", "edition": "Bulletin 2-2024, dated 2024-07-22, public page as read 2026-09-20", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The bulletin's public page on nacha.org, read 2026-09-20 for the RDFI posting question in the OC-5 us-ach coverage gaps.", "confidence": "medium" }, "currency": { "effective_since": "2024-07-22", "effective_to": null, "effective_note": "A RuleSource describes one edition of one document. This bulletin carries the date Nacha published it; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "Bulletin 2-2024, dated 2024-07-22, public page as read 2026-09-20", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.participants-a-wrong-account-type-code-is-corrected-not-refused", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.participants-posting-rests-on-the-account-number", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.nacha-providing-faster-funds-availability", "id": "src.nacha-providing-faster-funds-availability", "rail": "us-ach", "class": "RuleSource", "name": "Nacha, Providing Faster Funds Availability, rule effective 2019-09-20", "summary": "Nacha's public rule page setting withdrawal deadlines for Same Day ACH credits in the first two windows and for next day credits, with its time zone accommodations.", "publisher": "Nacha", "url": "https://www.nacha.org/rules/providing-faster-funds-availability", "source_class": "public_primary", "kind": "rule_change_page", "edition": "public rule page for the rule effective 2019-09-20, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, opened and read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2019-09-20", "effective_to": null, "effective_note": "Created by a drafting session on 2026-09-19. The page is archived by Nacha; its next day credit condition was later removed by the rule effective 2026-09-18. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "public rule page for the rule effective 2019-09-20, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.hours-same-day-credit-funds-availability", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.nacha-reversals-and-enforcement", "id": "src.nacha-reversals-and-enforcement", "rail": "us-ach", "class": "RuleSource", "name": "Nacha, ACH Network Rules: Reversals and Enforcement, rule effective 2021-06-30 and enforcement rule effective 2021-01-01", "summary": "Nacha's public page on the 2021 rules that narrowed permitted reversals, let an RDFI return an improper one, and reworked enforcement.", "publisher": "Nacha", "url": "https://www.nacha.org/rules/reversals-and-enforcement", "source_class": "public_primary", "kind": "rule_change_page", "edition": "public rule page for the reversals rule effective 2021-06-30 and the enforcement rule effective 2021-01-01, as read 2026-09-17", "access": "open", "consulted_on": "2026-09-18", "relations": [], "basis": { "sources": "Described by the 2026-09 Orca Core migration from the citations and checks of us-ach:decision-points, us-ach:finality, us-ach:messages, us-ach:participants, us-ach:recall, us-ach:refund and us-ach:return, which name it; the URL was confirmed to resolve on 2026-09-19 with a matching page title, and the document was not re-read for this record.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by the 2026-09 Orca Core migration from the us-ach rail fact citations. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "public rule page for the reversals rule effective 2021-06-30 and the enforcement rule effective 2021-01-01, as read 2026-09-17", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.decision-points-whether-a-reversal-was-proper", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.finality-no-recall-by-the-sender-once-the-file-has-gone", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.finality-reversals-exist-and-they-are-new-entries", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.finality-the-practical-window-returns-run-in-days-not", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.messages-reversal-is-a-field-value-not-a-message-type", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.participants-the-sanction-for-breaking-the-rules", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.recall-a-wrongly-used-reversal-can-be-sent-back", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.recall-how-a-reversal-must-be-formatted", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.recall-what-a-reversal-may-be-used-for", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.refund-the-ach-tool-that-carries-the-money-back", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.return-window-2-banking-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.return-window-60-calendar-days", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.nacha-same-day-ach-1-million-press-2022-03-18", "id": "src.nacha-same-day-ach-1-million-press-2022-03-18", "rail": "us-ach", "class": "RuleSource", "name": "Nacha, Same Day ACH Expansion to $1 Million Begins Today, press release dated 2022-03-18", "summary": "Nacha's announcement that the Same Day ACH per payment limit rose to $1 million on 2022-03-18.", "publisher": "Nacha", "url": "https://www.nacha.org/news/same-day-ach-expansion-1-million-begins-today", "source_class": "public_primary", "kind": "press_release", "edition": "press release dated 2022-03-18, as read 2026-09-17", "access": "open", "consulted_on": "2026-09-17", "relations": [], "basis": { "sources": "Described by the 2026-09 Orca Core migration from the citations and checks of us-ach:limits and us-ach:participants, which name it; the URL was confirmed to resolve on 2026-09-19 with a matching page title, and the document was not re-read for this record.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by the 2026-09 Orca Core migration from the us-ach rail fact citations. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "press release dated 2022-03-18, as read 2026-09-17", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.limits-the-same-day-ach-ceiling-today", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.participants-there-are-two-operators-not-one", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.nacha-same-day-ach-limit-10-million", "id": "src.nacha-same-day-ach-limit-10-million", "rail": "us-ach", "class": "RuleSource", "name": "Nacha, Increasing the Same Day ACH Dollar Limit to $10 Million, effective September 17, 2027", "summary": "Nacha's public page on raising the Same Day ACH per payment limit from $1 million to $10 million.", "publisher": "Nacha", "url": "https://www.nacha.org/rules/increasing-same-day-ach-dollar-limit-10-million-0", "source_class": "public_primary", "kind": "rule_change_page", "edition": "public rule page for the rule effective 2027-09-17, as read 2026-09-17", "access": "open", "consulted_on": "2026-09-18", "relations": [], "basis": { "sources": "Described by the 2026-09 Orca Core migration from the citations and checks of us-ach:limits, which name it; the URL was confirmed to resolve on 2026-09-19 with a matching page title, and the document was not re-read for this record.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by the 2026-09 Orca Core migration from the us-ach rail fact citations. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "public rule page for the rule effective 2027-09-17, as read 2026-09-17", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.limits-eligibility-limits-not-just-dollar-limits", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.limits-no-published-ceiling-on-non-same-day-entries", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.limits-other-dollar-limits-exist-and-are-not-published", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.limits-the-ceiling-that-is-coming", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:txn.iat", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.nacha-same-day-ach-phase-1", "id": "src.nacha-same-day-ach-phase-1", "rail": "us-ach", "class": "RuleSource", "name": "Nacha, Same Day ACH: Moving Payments Faster (Phase 1), rule effective 2016-09-23", "summary": "Nacha's public rule page for the original Same Day ACH rule, including the Same Day Entry Fee, who pays and receives it, and how returns, NOCs, reversals and operator returned entries are treated.", "publisher": "Nacha", "url": "https://www.nacha.org/rules/same-day-ach-moving-payments-faster-phase-1", "source_class": "public_primary", "kind": "rule_change_page", "edition": "public rule page for the rule effective 2016-09-23, as read 2026-09-19; its dollar limit figure of $25,000 is historical", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, opened and read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2016-09-23", "effective_to": null, "effective_note": "Created by a drafting session on 2026-09-19. The page describes the rule as adopted; later rules raised the dollar limit, so only its fee and processing statements are relied on. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "public rule page for the rule effective 2016-09-23, as read 2026-09-19; its dollar limit figure of $25,000 is historical", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.same-day-entry-fee", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.same-day-returns-regardless-of-forward", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.nacha-same-day-fee-no-change-2026-05-07", "id": "src.nacha-same-day-fee-no-change-2026-05-07", "rail": "us-ach", "class": "RuleSource", "name": "Nacha, Same Day ACH: No Change to the Amount of the Same Day ACH Fee, 2026-05-07", "summary": "Nacha's notice that the eight year volume review left the Same Day ACH fee unchanged for two more years, until the ten year review.", "publisher": "Nacha", "url": "https://www.nacha.org/news/same-day-ach-no-change-amount-same-day-ach-fee", "source_class": "public_primary", "kind": "news_release", "edition": "news item dated 2026-05-07, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, opened and read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2026-05-07", "effective_to": null, "effective_note": "Created by a drafting session on 2026-09-19. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "news item dated 2026-05-07, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.same-day-entry-fee", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.nacha-sanctions-compliance-return-code", "id": "src.nacha-sanctions-compliance-return-code", "rail": "us-ach", "class": "RuleSource", "name": "New Return Reason Code for Sanctions Compliance Obligations", "summary": "Nacha's public page announcing the R90 return reason for an RDFI's sanctions compliance obligations, with its window and effective date.", "publisher": "Nacha", "url": "https://www.nacha.org/rules/new-return-reason-code-sanctions-compliance-obligations", "source_class": "public_primary", "kind": "rule_change_page", "edition": "public rule page announcing R90, as read 2026-09-17", "access": "open", "consulted_on": "2026-09-17", "relations": [], "basis": { "sources": "Described from the corroboration entries of the us-ach reason codes that were checked against it (R90); the document was not re-read for this record.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by the 2026-09 Orca Core migration from the us-ach reason code corroborations. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "public rule page announcing R90, as read 2026-09-17", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.decision-points-whether-an-entry-breaches-sanctions-obligations", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.iat-ofac-hold-before-posting", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.return-a-new-return-code-with-its-own-window-is-dated", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.return-window-sanctions-determination", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.nacha-supplementing-fraud-detection-web-debits", "id": "src.nacha-supplementing-fraud-detection-web-debits", "rail": "us-ach", "class": "RuleSource", "name": "Nacha, Supplementing Fraud Detection Standards for WEB Debits", "summary": "Nacha's public rule page, with FAQs, for the rule that made account validation part of the fraud screening a WEB debit Originator must run.", "publisher": "Nacha", "url": "https://www.nacha.org/rules/supplementing-fraud-detection-standards-web-debits", "source_class": "public_primary", "kind": "rule_change_page", "edition": "public rule page with FAQs, rule effective 2021-03-19, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The page itself, opened and read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2021-03-19", "effective_to": null, "effective_note": "Created while drafting the WEB account validation, micro-entry, prenote and authorization records on 2026-09-19. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "public rule page with FAQs, rule effective 2021-03-19, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.micro-entries-receiver-confirmation", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.prenote-optional-zero-dollar-entry", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.web-debit-account-validation", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.web-validation-after-noc", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.web-validation-commercially-reasonable", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.web-validation-existing-accounts", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.web-validation-methods", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.web-validation-prenote-and-micro-entry-results", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.web-validation-what-it-confirms", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.nacha-third-parties-in-the-ach-network", "id": "src.nacha-third-parties-in-the-ach-network", "rail": "us-ach", "class": "RuleSource", "name": "Nacha, Third Parties in the ACH Network", "summary": "Nacha's public page defining Third-Party Service Provider, Third-Party Sender and Nested Third-Party Sender and summarising their audit, risk assessment and agreement duties.", "publisher": "Nacha", "url": "https://www.nacha.org/content/third-parties-ach-network", "source_class": "public_primary", "kind": "web_page", "edition": "web page as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, opened and read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by a drafting session on 2026-09-19; the page carries no date. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "web page as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:role.nested-third-party-sender", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:role.third-party-sender", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:role.third-party-service-provider", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.tps-annual-rules-compliance-audit", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.tps-origination-agreements", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.tps-risk-assessment", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.tps-which-role-an-intermediary-plays", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.nacha-third-party-sender-identification-tool", "id": "src.nacha-third-party-sender-identification-tool", "rail": "us-ach", "class": "RuleSource", "name": "Nacha, Third-Party Sender Identification Tool", "summary": "Nacha's public interactive tool, with an introduction, for working out whether a business acts as an Originator, a Third-Party Sender or another intermediary.", "publisher": "Nacha", "url": "https://www.nacha.org/content/third-party-sender-identification-tool", "source_class": "public_primary", "kind": "web_page", "edition": "web page as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, opened and read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by a drafting session on 2026-09-19; the page carries no date. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "web page as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.odfi-oversight-of-third-party-senders", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.nacha-third-party-sender-registration", "id": "src.nacha-third-party-sender-registration", "rail": "us-ach", "class": "RuleSource", "name": "Nacha, Third-Party Sender Registration, rule effective 2017-09-29", "summary": "Nacha's public rule page requiring ODFIs to register their Third-Party Senders, including nested ones, with its data, timing, supplemental information and enforcement.", "publisher": "Nacha", "url": "https://www.nacha.org/rules/third-party-sender-registration", "source_class": "public_primary", "kind": "rule_change_page", "edition": "public rule page for the rule effective 2017-09-29, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, opened and read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2017-09-29", "effective_to": null, "effective_note": "Created by a drafting session on 2026-09-19. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "public rule page for the rule effective 2017-09-29, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.odfi-oversight-of-third-party-senders", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.tps-company-name-and-identification", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.tps-registration", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.nacha-third-party-sender-roles", "id": "src.nacha-third-party-sender-roles", "rail": "us-ach", "class": "RuleSource", "name": "Nacha, Third-Party Sender Roles and Responsibilities, rule effective 2022-09-30", "summary": "Nacha's public page on Nested Third-Party Senders and each Third-Party Sender's own risk assessment.", "publisher": "Nacha", "url": "https://www.nacha.org/rules/third-party-sender-roles-and-responsibilities", "source_class": "public_primary", "kind": "rule_change_page", "edition": "public rule page for the rule effective 2022-09-30, as read 2026-09-17", "access": "open", "consulted_on": "2026-09-17", "relations": [], "basis": { "sources": "Described by the 2026-09 Orca Core migration from the citations and checks of us-ach:participants, which name it; the URL was confirmed to resolve on 2026-09-19 with a matching page title, and the document was not re-read for this record.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by the 2026-09 Orca Core migration from the us-ach rail fact citations. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "public rule page for the rule effective 2022-09-30, as read 2026-09-17", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:role.nested-third-party-sender", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:role.third-party-sender", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.odfi-oversight-of-third-party-senders", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.participants-third-party-senders-including-nested-ones", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.tps-annual-rules-compliance-audit", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.tps-nested-chain-of-agreements", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.tps-registration", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.tps-risk-assessment", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.nacha-web-proof-of-authorization-2022", "id": "src.nacha-web-proof-of-authorization-2022", "rail": "us-ach", "class": "RuleSource", "name": "Nacha, WEB Proof of Authorization Industry Practices", "summary": "A Nacha paper on what to collect and keep to prove a WEB debit authorization; it describes industry practice and cites rule subsections, and is not the rulebook.", "publisher": "Nacha", "url": "https://www.nacha.org/system/files/2022-11/WEB_Proof_of_Authorization_Industry_Practices.pdf", "source_class": "public_primary", "kind": "pdf_document", "edition": "copyright 2022, file dated 2022-11, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, opened and read in full on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created while drafting the WEB account validation, micro-entry, prenote and authorization records on 2026-09-19. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "copyright 2022, file dated 2022-11, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.authorization-general-requirements", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.authorization-web", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.nicolet-ach-quick-reference-guide", "id": "src.nicolet-ach-quick-reference-guide", "rail": "us-ach", "class": "RuleSource", "name": "Nicolet National Bank, Corporate User ACH Quick Reference Guide", "summary": "A bank's guide for its ACH Originators: authorizations by SEC code, prenotes, transaction codes, returns and NOCs.", "publisher": "Nicolet National Bank", "url": "https://www.nicoletbank.com/ach-quick-reference-guide-tm", "source_class": "secondary", "kind": "pdf_document", "edition": "undated guide referring to the 2024 Nacha Operating Rules & Guidelines, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, opened and read in full on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created while drafting the WEB account validation, micro-entry, prenote and authorization records on 2026-09-19. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "undated guide referring to the 2024 Nacha Operating Rules & Guidelines, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.authorization-ccd-ctx", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.authorization-general-requirements", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.authorization-ppd", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.authorization-tel", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.authorization-web", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.prenote-optional-zero-dollar-entry", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.prenote-wait-before-live-entries", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:txn.prenote", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.nys-courts-echeck-origination-numbers", "id": "src.nys-courts-echeck-origination-numbers", "rail": "us-ach", "class": "RuleSource", "name": "New York State Unified Court System, eCheck payments, ACH Debit Block and Filters", "summary": "A payee's public instruction to those paying it: where the payer's bank runs ACH blocks or filters, the payer gives the bank the payee's originating company identification so the debit is let through.", "publisher": "New York State Unified Court System", "url": "https://iappscontent.courts.state.ny.us/payments/echeck_origination_numbers.html", "source_class": "secondary", "kind": "payer_instruction", "edition": "public page, undated, as read 2026-09-20", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The court system's own payments page, read 2026-09-20 as an example of how a payee is authorised past a debit filter. It describes what one payee tells its payers, not a network rule, which is why it is secondary.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "A RuleSource describes one edition of one document. The page carries no date, so the read date stands for the edition; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "public page, undated, as read 2026-09-20", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.decision-points-blocking-or-filtering-incoming-debits", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.occ-bulletin-2006-39-ach-risk-management", "id": "src.occ-bulletin-2006-39-ach-risk-management", "rail": "us-ach", "class": "RuleSource", "name": "OCC Bulletin 2006-39, Automated Clearing House Activities: Risk Management Guidance", "summary": "The supervisor's standing guidance to national banks on originating ACH: underwriting an originator, knowing the originators behind a third-party sender, setting and reviewing credit and debit exposure thresholds, and monitoring return rates.", "publisher": "Office of the Comptroller of the Currency", "url": "https://www.occ.gov/news-issuances/bulletins/2006/bulletin-2006-39.html", "source_class": "public_primary", "kind": "supervisory_guidance", "edition": "Bulletin 2006-39, dated 2006-09-01, with the 2025-03-20 removal of its reputation risk references, as read 2026-09-20", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The OCC's own bulletin page on occ.gov, read 2026-09-20 for the ODFI exposure limit and onboarding questions in the OC-5 us-ach coverage gaps. The page states the bulletin is still in effect.", "confidence": "medium" }, "currency": { "effective_since": "2006-09-01", "effective_to": null, "effective_note": "A RuleSource describes one edition of one document. The bulletin is dated 2006-09-01 and the page notes an amendment on 2025-03-20 that removed its references to reputation risk; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "Bulletin 2006-39, dated 2006-09-01, as read 2026-09-20", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.limits-the-odfi-sets-an-exposure-limit-on-its-originator", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.participants-what-an-odfi-checks-before-an-originator-starts", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.ofac-letters-to-nacha-1997-2004", "id": "src.ofac-letters-to-nacha-1997-2004", "rail": "us-ach", "class": "RuleSource", "name": "OFAC, Guidance to the National Automated Clearing House Association (letters of 1997-03-20 and 2004-11-09)", "summary": "Two letters from OFAC's director to Nacha published by OFAC: the 1997 letter on OFAC duties in domestic ACH, and the 2004 letter on screening cross-border ACH entries, which names the duties of RDFIs on inbound and ODFIs on outbound entries.", "publisher": "Office of Foreign Assets Control, US Department of the Treasury", "url": "https://ofac.treasury.gov/media/17761/download", "source_class": "authoritative_primary", "kind": "pdf_document", "edition": "letters dated 1997-03-20 and 2004-11-09, scanned PDF as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "Opened and read in full (scanned images) on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "1997-03-20", "effective_to": null, "effective_note": "OFAC is the authority for sanctions duties, not for the Nacha rules; the letters predate IAT, and the 2004 letter describes the screening that IAT later formalised. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "letters dated 1997-03-20 and 2004-11-09, scanned PDF as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.iat-ofac-screening-duties", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-party-information-every-entry", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-replaced-cbr-and-pbr", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.plaid-same-day-micro-deposits", "id": "src.plaid-same-day-micro-deposits", "rail": "us-ach", "class": "RuleSource", "name": "Plaid documentation, Same-Day Micro-deposits", "summary": "A data provider's documentation of its same day micro-deposit verification flow and how it relates to instant methods.", "publisher": "Plaid", "url": "https://plaid.com/docs/auth/coverage/same-day/", "source_class": "secondary", "kind": "processor_reference", "edition": "public documentation, undated, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The page itself, opened and read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created while drafting the WEB account validation, micro-entry, prenote and authorization records on 2026-09-19. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "public documentation, undated, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.practice-instant-verification-and-micro-deposits", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "id": "src.popular-bank-ach-rules-awareness-guide-2025-04-02", "rail": "us-ach", "class": "RuleSource", "name": "Popular Bank, ACH Rules Awareness Guide for Businesses, revised 2025-04-02", "summary": "A bank's guide for its originating business customers: return reason codes and time frames, reversals, re-initiation, notifications of change and compliance.", "publisher": "Popular Bank", "url": "https://documents.popular.com/pdfs/PCB/ACH_Rules_Awareness_Guide.pdf", "source_class": "secondary", "kind": "bank_guide", "edition": "revised 2025-04-02", "access": "open", "consulted_on": "2026-09-18", "relations": [], "basis": { "sources": "Described by the 2026-09 Orca Core migration from the citations and checks of us-ach:decision-points, us-ach:finality, us-ach:liability, us-ach:limits, us-ach:messages, us-ach:recall, us-ach:refund and us-ach:return, which name it; the URL was confirmed to resolve on 2026-09-19 with a matching page title, and the document was not re-read for this record.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by the 2026-09 Orca Core migration from the us-ach rail fact citations. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "revised 2025-04-02", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.decision-points-whether-a-description-is-true", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.decision-points-whether-the-originator-keeps-its-access", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.decision-points-whether-to-honour-a-request-to-return", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.finality-reversals-exist-and-they-are-new-entries", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.finality-the-practical-window-returns-run-in-days-not", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.limits-the-limit-a-sender-actually-hits", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.messages-correcting-the-data-rather-than-the-payment", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.messages-reversal-is-a-field-value-not-a-message-type", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.messages-the-description-field-is-becoming-meaningful", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.noc-originator-applies-the-change", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.noc-rdfi-warrants-the-corrected-data", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.recall-asking-rather-than-reversing", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.recall-how-a-reversal-must-be-formatted", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.recall-reversing-a-whole-file", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.recall-the-receiving-side-is-not-obliged-to-fund-it", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.recall-the-two-clocks-on-a-reversal", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.recall-what-a-reversal-may-be-used-for", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.refund-a-business-has-no-equivalent-right", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.refund-the-ach-tool-that-carries-the-money-back", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.request-for-return-indemnity", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.return-re-presenting-a-failed-debit", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.return-returns-can-be-sent-back-again", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.return-what-the-consumer-has-to-sign", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.return-window-2-banking-days", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.return-window-60-calendar-days", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.reg-e-12-cfr-1005", "id": "src.reg-e-12-cfr-1005", "rail": "us-ach", "class": "RuleSource", "name": "12 CFR Part 1005 (Regulation E), eCFR current text", "summary": "The regulation implementing the Electronic Fund Transfer Act: coverage, preauthorized transfers, error resolution and consumer liability.", "publisher": "Consumer Financial Protection Bureau (eCFR)", "url": "https://www.ecfr.gov/current/title-12/part-1005", "source_class": "authoritative_primary", "kind": "regulation", "edition": "current eCFR text as read 2026-09-17", "access": "open", "consulted_on": "2026-09-18", "relations": [], "basis": { "sources": "Described by the 2026-09 Orca Core migration from the citations and checks of us-ach:consumer-law, us-ach:decision-points, us-ach:finality, us-ach:liability and us-ach:refund, which name it; the URL was confirmed to resolve on 2026-09-19 with a matching page title, and the document was not re-read for this record.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by the 2026-09 Orca Core migration from the us-ach rail fact citations. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "current eCFR text as read 2026-09-17", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:exc.reg-e-error-claim", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.consumer-law-authorisation-for-a-recurring-debit-must-be", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.consumer-law-credit-as-of-the-day-funds-arrive", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.consumer-law-government-benefit-accounts-are-inside-the", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.consumer-law-no-forcing-a-consumer-onto-the-rail", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.consumer-law-notice-that-an-incoming-credit-arrived", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.consumer-law-the-error-clock", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.consumer-law-the-stop-payment-right", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.consumer-law-warning-when-the-amount-changes", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.consumer-law-what-is-covered", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.decision-points-whether-a-consumers-claim-is-an-error", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.finality-third-layer-the-consumers-claim-runs-on-its-own", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.liability-the-60-day-line-on-a-statement", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.liability-the-consumers-exposure-is-capped", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.refund-a-business-has-no-equivalent-right", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.refund-longer-clocks-for-new-accounts-and-some", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.refund-provisional-credit-while-the-bank-investigates", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.refund-the-consumers-statutory-route", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.refund-why-95-days-and-not-60", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.reg-j-12-cfr-210", "id": "src.reg-j-12-cfr-210", "rail": "us-ach", "class": "RuleSource", "name": "12 CFR Part 210 (Regulation J), eCFR current text", "summary": "The Federal Reserve regulation on collection of items and funds transfers through the Reserve Banks, with its appendix commentary on Article 4A.", "publisher": "Board of Governors of the Federal Reserve System (eCFR)", "url": "https://www.ecfr.gov/current/title-12/part-210", "source_class": "authoritative_primary", "kind": "regulation", "edition": "current eCFR text as read 2026-09-17", "access": "open", "consulted_on": "2026-09-18", "relations": [], "basis": { "sources": "Described by the 2026-09 Orca Core migration from the citations and checks of us-ach:finality, which name it; the URL was confirmed to resolve on 2026-09-19 with a matching page title, and the document was not re-read for this record.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by the 2026-09 Orca Core migration from the us-ach rail fact citations. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "current eCFR text as read 2026-09-17", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.finality-ach-is-not-a-fedwire-funds-transfer-and", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.finality-second-layer-article-4a-and-only-for-some", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.regions-tps-annual-ach-audit-2026-05-07", "id": "src.regions-tps-annual-ach-audit-2026-05-07", "rail": "us-ach", "class": "RuleSource", "name": "Regions Bank, Third-party senders: what to know about an annual ACH audit, 2026-05-07", "summary": "A bank's public article on the annual Rules compliance audit for Third-Party Senders: who must do it, by when, record keeping and the items audited.", "publisher": "Regions Bank", "url": "https://www.regions.com/insights/commercial/article/third-party-sender-ach-audit", "source_class": "secondary", "kind": "web_page", "edition": "article published 2026-05-07, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, opened and read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2026-05-07", "effective_to": null, "effective_note": "Created by a drafting session on 2026-09-19. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "article published 2026-05-07, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.tps-annual-rules-compliance-audit", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.tps-origination-agreements", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.regions-tps-warranties-obligations-2026-08-28", "id": "src.regions-tps-warranties-obligations-2026-08-28", "rail": "us-ach", "class": "RuleSource", "name": "Regions Bank, Nacha warranties and obligations for third-party senders, 2026-08-28", "summary": "A bank's public article on what a Third-Party Sender must do and warrant under the Nacha rules, and its own bar on nested senders.", "publisher": "Regions Bank", "url": "https://www.regions.com/insights/commercial/article/nacha-third-party-sender-warranties-obligations", "source_class": "secondary", "kind": "web_page", "edition": "article published 2026-08-28, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, opened and read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "2026-08-28", "effective_to": null, "effective_note": "Created by a drafting session on 2026-09-19. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "article published 2026-08-28, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.tps-duties-and-warranties", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.tps-nested-chain-of-agreements", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.slash-ach-blocks-and-filters-2026-05-26", "id": "src.slash-ach-blocks-and-filters-2026-05-26", "rail": "us-ach", "class": "RuleSource", "name": "Slash, ACH Blocks and Filters: How Businesses Can Prevent Fraud", "summary": "A financial technology company's public explainer on ACH blocks and filters, which names the fields a filter matches on, says credits are handled apart from debits, and names the return code a blocked or filtered debit is typically sent back with.", "publisher": "Slash", "url": "https://www.slash.com/blog/ach-blocks-and-filters", "source_class": "secondary", "kind": "explainer", "edition": "dated 2026-05-26, as read 2026-09-20", "access": "open", "consulted_on": "2026-09-20", "relations": [], "basis": { "sources": "The company's own public article, read 2026-09-20 for the return code a blocked debit draws, which no bank or authority source read for this work named. It is a vendor explainer, which is why it is secondary and why the claim it carries is marked unverified where the corpus uses it.", "confidence": "low" }, "currency": { "effective_since": "2026-05-26", "effective_to": null, "effective_note": "A RuleSource describes one edition of one document. The article gives its own date; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "dated 2026-05-26, as read 2026-09-20", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.return-what-a-blocked-debit-comes-back-as", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.stripe-ach-accept-a-payment", "id": "src.stripe-ach-accept-a-payment", "rail": "us-ach", "class": "RuleSource", "name": "Stripe documentation, Accept an ACH Direct Debit payment (Direct API)", "summary": "A processor's integration guide covering instant bank verification and its micro-deposit fallback.", "publisher": "Stripe", "url": "https://docs.stripe.com/payments/ach-direct-debit/accept-a-payment.md?payment-ui=direct-api", "source_class": "secondary", "kind": "processor_reference", "edition": "public documentation, undated, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The page itself, opened and read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created while drafting the WEB account validation, micro-entry, prenote and authorization records on 2026-09-19. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "public documentation, undated, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.practice-instant-verification-and-micro-deposits", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.stripe-ach-company-ids", "id": "src.stripe-ach-company-ids", "rail": "us-ach", "class": "RuleSource", "name": "Stripe, ACH company IDs for Stripe", "summary": "A processor's public help page giving the two company IDs it uses to collect ACH debits and send ACH credits on behalf of all its users.", "publisher": "Stripe", "url": "https://support.stripe.com/questions/ach-direct-debit-company-ids-for-stripe", "source_class": "secondary", "kind": "web_page", "edition": "help page as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, opened and read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by a drafting session on 2026-09-19; the page carries no date. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "help page as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.tps-company-name-and-identification", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.stripe-ach-direct-debit", "id": "src.stripe-ach-direct-debit", "rail": "us-ach", "class": "RuleSource", "name": "Stripe documentation, ACH Direct Debit payments", "summary": "A processor's documentation of ACH debits it originates: timing, cancellation, refunds, retries and blocked accounts.", "publisher": "Stripe", "url": "https://docs.stripe.com/payments/ach-direct-debit", "source_class": "secondary", "kind": "processor_reference", "edition": "public documentation, undated, as read 2026-09-17", "access": "open", "consulted_on": "2026-09-17", "relations": [], "basis": { "sources": "Described by the 2026-09 Orca Core migration from the citations and checks of us-ach:limits, us-ach:recall, us-ach:refund and us-ach:return, which name it; the URL was confirmed to resolve on 2026-09-19 with a matching page title, and the document was not re-read for this record.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by the 2026-09 Orca Core migration from the us-ach rail fact citations. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "public documentation, undated, as read 2026-09-17", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.limits-the-limit-a-sender-actually-hits", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.practice-instant-verification-and-micro-deposits", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.recall-before-the-file-leaves-it-is-a-different", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.refund-a-merchant-refund-is-a-new-payment", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.return-re-presenting-a-failed-debit", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.return-what-a-processor-calls-a-late-return", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.stripe-ach-sec-codes", "id": "src.stripe-ach-sec-codes", "rail": "us-ach", "class": "RuleSource", "name": "Stripe documentation, Overview of ACH SEC codes", "summary": "A processor's explanation of Standard Entry Class codes and which it uses.", "publisher": "Stripe", "url": "https://docs.stripe.com/payments/ach-direct-debit/sec-codes", "source_class": "secondary", "kind": "processor_reference", "edition": "public documentation, undated, as read 2026-09-17", "access": "open", "consulted_on": "2026-09-17", "relations": [], "basis": { "sources": "Described by the 2026-09 Orca Core migration from the citations and checks of us-ach:messages, which name it; the URL was confirmed to resolve on 2026-09-19 with a matching page title, and the document was not re-read for this record.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by the 2026-09 Orca Core migration from the us-ach rail fact citations. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "public documentation, undated, as read 2026-09-17", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.messages-the-standard-entry-class-code", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.stripe-nacha-validation-rule-faq", "id": "src.stripe-nacha-validation-rule-faq", "rail": "us-ach", "class": "RuleSource", "name": "Stripe Support, Nacha WEB debit account validation rule", "summary": "A processor's support article on the WEB debit account validation rule and how its products meet it.", "publisher": "Stripe", "url": "https://support.stripe.com/questions/nacha-bank-account-validation-rule", "source_class": "secondary", "kind": "processor_reference", "edition": "public support article, undated, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The page itself, opened and read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created while drafting the WEB account validation, micro-entry, prenote and authorization records on 2026-09-19. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "public support article, undated, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.practice-instant-verification-and-micro-deposits", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.web-debit-account-validation", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.web-validation-what-it-confirms", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.tompkins-originating-ach-quick-reference", "id": "src.tompkins-originating-ach-quick-reference", "rail": "us-ach", "class": "RuleSource", "name": "Tompkins Bank & Trust, Originating ACH Entries Quick Reference Guide", "summary": "A bank's guide for its ACH Originators: general authorization requirements and the obligations and warranties for each SEC code it offers.", "publisher": "Tompkins Bank & Trust", "url": "https://www.tompkinsbank.com/assets/files/Gdhq0onu", "source_class": "secondary", "kind": "pdf_document", "edition": "undated guide, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, opened and read in full on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created while drafting the WEB account validation, micro-entry, prenote and authorization records on 2026-09-19. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "undated guide, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.authorization-ccd-ctx", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.authorization-general-requirements", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.authorization-ppd", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.authorization-tel", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.authorization-web", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.micro-entries-definition-and-labels", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.web-debit-account-validation", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.web-validation-after-noc", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.web-validation-methods", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:txn.web", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.treasury-fr-2017-09-11-ach-participation", "id": "src.treasury-fr-2017-09-11-ach-participation", "rail": "us-ach", "class": "RuleSource", "name": "Department of the Treasury, Federal Government Participation in the Automated Clearing House, final rule, 82 FR 42597", "summary": "The Fiscal Service final rule incorporating Nacha rule changes into 31 CFR part 210; its preamble describes each change, including the 2014 prenotification waiting period.", "publisher": "Department of the Treasury, Bureau of the Fiscal Service (Federal Register, via GovInfo)", "url": "https://www.govinfo.gov/content/pkg/FR-2017-09-11/html/2017-19135.htm", "source_class": "public_primary", "kind": "federal_register_rule", "edition": "82 FR 42597 to 42609, published 2017-09-11, as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The Federal Register text on GovInfo, opened and read on 2026-09-19 for the prenotification item.", "confidence": "medium" }, "currency": { "effective_since": "2017-09-11", "effective_to": null, "effective_note": "Created while drafting the WEB account validation, micro-entry, prenote and authorization records on 2026-09-19. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "82 FR 42597 to 42609, published 2017-09-11, as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.prenote-response-deadline-and-originator-action", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.prenote-wait-before-live-entries", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:src.treasury-green-book-2025-03", "id": "src.treasury-green-book-2025-03", "rail": "us-ach", "class": "RuleSource", "name": "Green Book, A Guide to Federal Government ACH Payments, edition published 2025-03", "summary": "Treasury's guide for financial institutions receiving federal ACH payments and sending collections to the government: returns, reclamations and notifications of change.", "publisher": "US Treasury Bureau of the Fiscal Service", "url": "https://tfx.treasury.gov/system/files/2025-03/greenbook-full.pdf", "source_class": "public_primary", "kind": "guide", "edition": "edition published 2025-03", "access": "open", "consulted_on": "2026-09-17", "relations": [], "basis": { "sources": "Described by the 2026-09 Orca Core migration from the citations and checks of us-ach:messages, us-ach:refund and us-ach:return, which name it; the URL was confirmed to resolve on 2026-09-19 with a matching page title, and the document was not re-read for this record.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by the 2026-09 Orca Core migration from the us-ach rail fact citations. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "edition published 2025-03", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:exc.dishonored-return", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:exc.notification-of-change", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:exc.refused-notification-of-change", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.format-addenda-indicator-and-linking", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-dishonored-return-addenda", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-enr-entry-codes", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.format-return-entry-construction", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.messages-correcting-the-data-rather-than-the-payment", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.messages-the-record-types-a-payment-uses", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.messages-what-identifies-an-entry-afterwards", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.noc-federal-agencies-accept-six-codes", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.refund-federal-payments-have-their-own-recovery-route", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.refused-noc-window-none-found", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:rule.return-returns-can-be-sent-back-again", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:txn.cor", "type": "sourced_from", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:src.umacha-third-party-services", "id": "src.umacha-third-party-services", "rail": "us-ach", "class": "RuleSource", "name": "UMACHA, Third-Party Services", "summary": "A regional payments association's public page defining Third-Party Senders and Nested Third-Party Senders and stating their annual audit and risk assessment duties.", "publisher": "UMACHA", "url": "https://www.umacha.org/third-party_services.php", "source_class": "secondary", "kind": "web_page", "edition": "web page as read 2026-09-19", "access": "open", "consulted_on": "2026-09-19", "relations": [], "basis": { "sources": "The document itself, opened and read on 2026-09-19.", "confidence": "medium" }, "currency": { "effective_since": "See edition", "effective_to": null, "effective_note": "Created by a drafting session on 2026-09-19; the page carries no date. A RuleSource describes one edition of a document; its status stays draft and the monthly watch dates it through consulted_on.", "source_edition": "web page as read 2026-09-19", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:role.nested-third-party-sender", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:role.third-party-sender", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.tps-annual-rules-compliance-audit", "type": "sourced_from", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.tps-risk-assessment", "type": "sourced_from", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:state.awaiting-settlement", "id": "state.awaiting-settlement", "rail": "us-ach", "class": "LifecycleState", "name": "Processed, awaiting settlement", "summary": "The file has been taken in and processed and the entry now has a settlement date and time: one of the same day times on the day of receipt if it passed every same day test, and otherwise the single morning event on the banking day its effective date points at. Nothing has moved between the banks. The entry is not safe here either. A Reserve Bank acknowledges the file it received, and the acknowledgement says only that: not that the items are accepted, and the Reserve Bank may still reject any of them. One that expects a settlement account to be short at settlement time may decline to settle for the item at all. Whether the Receiver can already see the money is the receiving bank's own choice rather than the network's, which is why money_moved reads unknown rather than no.", "terminal": false, "money_moved": "unknown", "visible_as": "pending at both ends, and this is the condition most apps mean by pending. Some receiving banks advance their own money and show a credit here, which is why a payroll credit sometimes lands a day early and sometimes does not", "relations": [ { "type": "precedes", "to": "us-ach:state.settled", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "precedes", "to": "us-ach:state.posted", "note": "where the receiving bank advances its own money, the entry can be on the account before it settles", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "precedes", "to": "us-ach:state.returned", "note": "the operator's reject at processing comes back to the sending side as a return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.messages-the-operator-acknowledges-a-file-it-has-taken-in", "note": "entering the state, and why the acknowledgement is not acceptance", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.settlement-which-day-is-the-settlement-day", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.settlement-same-day-settlement-clock-times", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.settlement-future-dated-settlement-clock-time", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.same-day-ineligible-entry-settles-next-day", "note": "which settlement day the entry gets", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.finality-settlement-can-also-be-refused-before-it-happens", "note": "leaving the state without settling", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.decision-points-whether-funds-appear-before-settlement", "note": "why money_moved is unknown and not no", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted from the us-ach Rules this record is governed_by, every one of them already in the corpus. No document was opened for this record. No source Orca holds publishes a lifecycle state model for ACH, so which conditions are worth naming, and the order they run in, are Orca's. [Unverified] This closes decision 4 of OC-8: money_moved is unknown because the corpus holds a Rule saying early availability is some banks' practice and not a requirement, so Orca cannot say from the network's position whether the Receiver has the money. The acknowledgement and refusal Rules are the Federal Reserve's own, so what the private operator does at the same point is not held.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "First LifecycleState slice, 2026-09-20. The state is Orca's grouping of Rules already in the corpus; no rule change is claimed and no date of its own is known.", "source_edition": "As the Rules this state is governed_by; no document was opened for this record.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Operating Circular 4 confirms the Reserve Banks acknowledge a file they have received and performed limited processing on without that acknowledgement meaning the items are accepted, that a Reserve Bank may still refuse to settle an item, batch or file at its own discretion, and that Appendix B fixes which banking day is the settlement day from the effective date and window, supporting the claim that the entry has a settlement date and time here but is not yet safe and may still leave this state without settling." }, { "source": "us-ach:src.fedach-processing-schedule-2022-09-12", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "The FedACH Processing Schedule confirms same day settlement clock times for each submission window and a future dated settlement clock time of 8:30am Eastern the next banking day, supporting the specific settlement times this state's governing rules name." }, { "source": "us-ach:src.frb-same-day-ach-faq", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "The Federal Reserve's Same Day ACH FAQ confirms that an item which fails a same day eligibility edit, such as the value limit, still settles the next business day instead of being blocked, supporting the claim that an entry ineligible for same day settlement clears one day later rather than failing outright." }, { "source": "us-ach:src.nacha-abcs-of-ach", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Nacha's ABCs of ACH page confirms that some banks and credit unions advance their own funds to a customer before settlement actually occurs, resulting in early availability, supporting the claim that whether the Receiver already sees the money at this point is the receiving bank's own choice rather than something the network decides, and the money_moved value of unknown rather than no." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:state.held-at-the-operator", "type": "precedes", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.sent-to-the-operator", "type": "precedes", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:state.dishonor-contested", "id": "state.dishonor-contested", "rail": "us-ach", "class": "LifecycleState", "name": "Dishonor contested by the RDFI", "summary": "The receiving bank has answered the dishonour inside 2 banking days of its settlement date, either disputing it, on the ground that the original return was in time, was not a duplicate and carried no error, or that the dishonour itself was late or misrouted, or correcting the fields the ODFI said were wrong. A contest sent in time and without errors has to be accepted: the network offers no further round, which makes this the last condition a payment can reach inside it. Anything still in dispute between the two banks is settled outside the ACH Network. The route is closed to IAT.", "terminal": true, "money_moved": "yes", "visible_as": "nothing further arrives in the network; whatever the banks still disagree about they take up between themselves", "relations": [ { "type": "governed_by", "to": "us-ach:rule.contest-window-2-banking-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.contested-dishonor-ends-the-network-dispute", "note": "why this state is terminal", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.iat-no-dishonored-returns", "note": "the entries that cannot enter this state", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted from the us-ach Rules this record is governed_by, every one of them already in the corpus. No document was opened for this record. No source Orca holds publishes a lifecycle state model for ACH, so which conditions are worth naming, and the order they run in, are Orca's. [Unverified] terminal is true on one Rule, which says a proper contest ends the dispute inside the network and leaves any remainder to be settled outside it. That the banks may still argue elsewhere is not a state of the payment on this rail.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "First LifecycleState slice, 2026-09-20. The state is Orca's grouping of Rules already in the corpus; no rule change is claimed and no date of its own is known.", "source_edition": "As the Rules this state is governed_by; no document was opened for this record.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Jefferson Bank's Obligations of Originators guide confirms that an RDFI must respond within two banking days of the settlement date of a dishonored return, and that if the RDFI properly contests it on time and without error the ODFI must accept the entry and resolve any further dispute outside the ACH Network, supporting the two banking day window, the terminal flag and the claim that nothing further arrives through the network." }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "CBS Bank's Quick Reference Guide confirms the same two banking day contest window and that the contested dishonored return codes are usable for all entries except IAT, supporting the window and the exclusion of IAT from this state." }, { "source": "us-ach:src.nacha-iat-faqs-web", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Nacha's International ACH Transactions FAQ page confirms that dishonored and contested dishonored return codes are not allowed for use with IAT entries and that any such dispute is handled outside the ACH Network, supporting the claim that the route into this state is closed to IAT." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:exc.contested-dishonored-return", "type": "enters", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.return-dishonored", "type": "precedes", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:state.funds-available", "id": "state.funds-available", "rail": "us-ach", "class": "LifecycleState", "name": "Funds available to the side that received them", "summary": "The money can be used. On a credit to a Receiver the receiving bank has to let it be withdrawn by the deadline for the kind of entry and the window it arrived in, and nothing stops the bank releasing it sooner; a bank far enough west of the Atlantic time zone has longer than the rest. On a debit the originating side has its credit from the settlement date, although a Reserve Bank may hold back its use where it doubts the sending bank's account will cover a return. Available is still not safe: the ordinary return window runs for 2 banking days after settlement and an unauthorised consumer debit can come back for 60 calendar days, so money can be spent and then taken back.", "terminal": false, "money_moved": "yes", "visible_as": "the Receiver can withdraw a credit; on a debit the originating side has the proceeds on its own account", "relations": [ { "type": "precedes", "to": "us-ach:state.returned", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.hours-when-the-receiver-can-use-the-money", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.hours-same-day-credit-funds-availability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.hours-one-geographic-exception-to-that-availability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.settlement-credit-given-for-a-debit-is-not-the-same-as", "note": "the debit side of the same condition", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.finality-the-practical-window-returns-run-in-days-not", "note": "why this state is not terminal", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted from the us-ach Rules this record is governed_by, every one of them already in the corpus. No document was opened for this record. No source Orca holds publishes a lifecycle state model for ACH, so which conditions are worth naming, and the order they run in, are Orca's. [Unverified] Three availability Rules cover a credit to the Receiver and one settlement Rule covers the originating side of a debit. Orca reads them as one condition, the value being usable by whoever received it; no source groups them.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "First LifecycleState slice, 2026-09-20. The state is Orca's grouping of Rules already in the corpus; no rule change is claimed and no date of its own is known.", "source_edition": "As the Rules this state is governed_by; no document was opened for this record.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-funds-availability-non-same-day-credits", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Nacha's Funds Availability Requirements for Non-Same Day Credit Entries page confirms a 9:00am RDFI local time deadline on the settlement date for making a non-same-day credit available for withdrawal, supporting the claim about when the Receiver can use the money." }, { "source": "us-ach:src.nacha-providing-faster-funds-availability", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Nacha's Providing Faster Funds Availability page confirms 1:30pm and 5:00pm RDFI local time deadlines for Same Day ACH credits by window, and a geographic exception giving institutions outside the Atlantic time zone until 9:00am local time the following business day, supporting the claim that a bank further west of the Atlantic time zone has longer than the rest." }, { "source": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Operating Circular 4 paragraph 11.1(a) confirms that credit given for a debit item is available for use from the settlement date, subject to the Reserve Bank's discretion to refuse its use if it doubts the sending bank's settlement account will cover a chargeback or return, supporting the claim that the originating side has its credit from the settlement date on a debit, and that this state is not terminal because a return can still follow." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:state.posted", "type": "precedes", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:state.held-at-the-operator", "id": "state.held-at-the-operator", "rail": "us-ach", "class": "LifecycleState", "name": "Held at the operator, waiting on the sending bank", "summary": "The operator has the file and will not carry it forward until the sending side says to. Two routes reach this condition. A Reserve Bank has told the sending bank it is holding what looks like a duplicate file, or another problem with it, and will not process it unheard from; or the FedACH Risk Origination Monitoring Service has stopped a batch that crossed a dollar threshold the ODFI itself set, and only the ODFI can let it go. Waiting here costs the payment its day: a batch let go after the last same day deadline settles on the next business day, and a batch nobody answers for takes whatever end of day default the ODFI chose. Both Rules behind this state are the Federal Reserve's, so Orca cannot say whether the private operator holds a file the same way.", "terminal": false, "money_moved": "no", "visible_as": "pending, with nothing that shows the delay; the hold is visible to the ODFI through its operator services and to nobody else", "relations": [ { "type": "precedes", "to": "us-ach:state.awaiting-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.messages-a-suspected-duplicate-file-waits-for-the-sender", "note": "the operator's own query holds the file", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.same-day-risk-pended-batches", "note": "the ODFI's monitoring service holds the batch, and what a late release costs", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted from the us-ach Rules this record is governed_by, every one of them already in the corpus. No document was opened for this record. No source Orca holds publishes a lifecycle state model for ACH, so which conditions are worth naming, and the order they run in, are Orca's. [Unverified] Two Rules, one about a Reserve Bank waiting on the sending bank and one about a batch pended by the FedACH Risk Origination Monitoring Service, describe the same condition from two directions: the operator holds the payment and the sending side has to act.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "First LifecycleState slice, 2026-09-20. The state is Orca's grouping of Rules already in the corpus; no rule change is claimed and no date of its own is known.", "source_edition": "As the Rules this state is governed_by; no document was opened for this record.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Operating Circular 4 confirms that when a Reserve Bank notifies a sending bank of a suspected duplicate file or other problem it will not process the file without the sending bank's or its agent's approval, supporting the claim that the file is held until the sending side responds and that the hold is visible to the sending bank rather than the network generally." }, { "source": "us-ach:src.frb-same-day-ach-faq", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "The Federal Reserve's Same Day ACH FAQ confirms that a batch pended by the FedACH Risk Origination Monitoring Service can be released only by the ODFI, that release after the final same day cutoff results in next day settlement instead, and that an unreleased batch settles under whatever default the ODFI configured, supporting the claim that both routes into this state leave the sending side in control and that waiting here costs the payment its same day settlement." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:state.sent-to-the-operator", "type": "precedes", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:state.originated", "id": "state.originated", "rail": "us-ach", "class": "LifecycleState", "name": "Originated, not yet sent", "summary": "The Originator has instructed the payment and it is still on the originating side, in the Originator's, a Third-Party Sender's, a processor's or the ODFI's own queue. No ACH Operator has it, so there is no entry to recall: stopping the payment here is a matter of whoever holds the queue, not of the network's rules. Where the originating side uses a service with a separate release step, the payment leaves this condition only when every step is done and the whole file has been received inside a deadline, and one that misses every deadline of the day never becomes a payment at all.", "terminal": false, "money_moved": "no", "visible_as": "the Originator's or the platform's app shows the payment as submitted, scheduled or pending; nothing is visible at either bank", "relations": [ { "type": "precedes", "to": "us-ach:state.sent-to-the-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.recall-before-the-file-leaves-it-is-a-different", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.hours-release-not-transmission-is-what-counts", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.hours-same-day-transmission-deadlines", "note": "leaving this state in time for same day settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.same-day-no-deadline-extensions", "note": "there is no extra time for a file that misses a window", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted from the us-ach Rules this record is governed_by, every one of them already in the corpus. No document was opened for this record. No source Orca holds publishes a lifecycle state model for ACH, so which conditions are worth naming, and the order they run in, are Orca's. [Unverified] The condition is Orca's reading of one recall Rule, which says a payment still in a queue can usually be stopped because nothing has been sent, and of the release and deadline Rules that say when it stops being in the queue.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "First LifecycleState slice, 2026-09-20. The state is Orca's grouping of Rules already in the corpus; no rule change is claimed and no date of its own is known.", "source_edition": "As the Rules this state is governed_by; no document was opened for this record.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Operating Circular 4 confirms that release for processing, not transmission, is what fixes the moment a file leaves the originating side, that a file not released by the end of day deadline is rejected or deleted, and that a same day file missed after the final same day deadline processes as a next day item instead, supporting this state's account of when a payment stops being originated and its precedes link to being sent to the operator." }, { "source": "us-ach:src.frb-same-day-ach-faq", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "The Federal Reserve's Same Day ACH FAQ confirms that no extensions of Same Day ACH deadlines are allowed, supporting the claim that a file which misses every deadline of the day gets no extra time rather than becoming a payment on a later same day window." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:state.posted", "id": "state.posted", "rail": "us-ach", "class": "LifecycleState", "name": "Posted to the Receiver's account", "summary": "The receiving bank has put the entry on the Receiver's account. It may decide where the entry posts from the account number alone, and a receiver name that does not match the name on that account is not by itself a reason to turn the entry away. A preauthorised credit is dated as of the day the funds for it are received, so the bank cannot keep the value between settlement and posting. Posting is not the same as the money being usable, and it is not the end of the entry: a return can still follow, and on a consumer debit the account holder's own statutory clock starts from the statement this entry appears on. An IAT the receiving bank suspects on a sanctions screen stays out of this condition until it has been reviewed and cleared.", "terminal": false, "money_moved": "yes", "visible_as": "the entry is on the Receiver's account and on the statement, a credit dated as of the day the funds for it arrived", "relations": [ { "type": "precedes", "to": "us-ach:state.funds-available", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "precedes", "to": "us-ach:state.returned", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "precedes", "to": "us-ach:state.recredited-under-regulation-e", "note": "a consumer who sees the entry on a statement can start the statutory claim", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.participants-posting-rests-on-the-account-number", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.consumer-law-credit-as-of-the-day-funds-arrive", "note": "the date the entry takes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.iat-ofac-hold-before-posting", "note": "an entry that must be kept out of this state until cleared", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted from the us-ach Rules this record is governed_by, every one of them already in the corpus. No document was opened for this record. No source Orca holds publishes a lifecycle state model for ACH, so which conditions are worth naming, and the order they run in, are Orca's. [Unverified] Three Rules say what posting rests on, what date it takes and when it must wait. None of them calls posting a state, and no Rule in the corpus fixes when the operator delivers the entry to the receiving bank, so how long a payment waits between processing and posting is not something Orca can answer.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "First LifecycleState slice, 2026-09-20. The state is Orca's grouping of Rules already in the corpus; no rule change is claimed and no date of its own is known.", "source_edition": "As the Rules this state is governed_by; no document was opened for this record.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-ops-bulletin-2-2024-individual-name", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Nacha ACH Operations Bulletin 2-2024 confirms that a receiving bank may rely solely on the account number in an entry to post it regardless of whether the receiver name matches the name on the account, and that a mismatched name alone is not grounds to return the entry, supporting the claim that posting rests on the account number." }, { "source": "us-ach:src.reg-e-12-cfr-1005", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "12 CFR 1005.10(a)(3), read through the eCFR versioner API, confirms that a financial institution receiving a preauthorized credit transfer must credit the amount as of the date the funds for the transfer are received, supporting the claim that a preauthorised credit is dated as of the day the funds for it arrive and that the bank cannot keep the value between settlement and posting." }, { "source": "us-ach:src.nacha-iat-faqs-web", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Nacha's International ACH Transactions FAQ page confirms that an RDFI should screen IAT transactions before posting and that a suspect item must be reviewed and cleared before it is posted, supporting the claim that a suspected IAT entry is kept out of this state until it has been reviewed and cleared." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:state.awaiting-settlement", "type": "precedes", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.settled", "type": "precedes", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:state.recredited-under-regulation-e", "id": "state.recredited-under-regulation-e", "rail": "us-ach", "class": "LifecycleState", "name": "Recredited to the consumer under Regulation E", "summary": "The consumer's own bank has put the disputed amount back on the account, either because it decided an error occurred or provisionally while it keeps investigating. The clock is statutory and owes nothing to the ACH windows: the consumer has 60 days from the statement that first showed the item, the bank has 10 business days to decide or up to 45 if it credits inside those 10, and longer again for a new account or certain transfers, and the credit has to be left usable. What has changed is the consumer's position, not the entry's, which settled and posted as it was: whether the bank recovers from the originating side through a return or a warranty claim is a separate question, and it may owe the recredit even after the return window has shut. A provisional credit can be taken away again after notice where the bank finds no error. An account held for business purposes has no equivalent route.", "terminal": false, "money_moved": "yes", "visible_as": "the consumer's statement shows the money back, sometimes marked provisional or temporary while the bank finishes its investigation", "relations": [ { "type": "precedes", "to": "us-ach:state.returned", "note": "the bank may then try to recover from the originating side through an ACH return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.consumer-law-the-error-clock", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.refund-the-consumers-statutory-route", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.refund-provisional-credit-while-the-bank-investigates", "note": "what makes the credit provisional, and reversible", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.refund-longer-clocks-for-new-accounts-and-some", "note": "the longer clocks", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.finality-third-layer-the-consumers-claim-runs-on-its-own", "note": "why this state does not depend on the return windows", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.refund-a-business-has-no-equivalent-right", "note": "who cannot enter this state", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted from the us-ach Rules this record is governed_by, every one of them already in the corpus. No document was opened for this record. No source Orca holds publishes a lifecycle state model for ACH, so which conditions are worth naming, and the order they run in, are Orca's. [Unverified] This is the one state Orca records that belongs to the consumer's account rather than to the entry between the banks, and it is recorded because the Regulation E error claim is the only Exception in us-ach that moves money without changing anything else about the entry. A reader asking why the money came back but the network shows a failed dispute is asking about this condition.", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "First LifecycleState slice, 2026-09-20. The state is Orca's grouping of Rules already in the corpus; no rule change is claimed and no date of its own is known.", "source_edition": "As the Rules this state is governed_by; no document was opened for this record.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.reg-e-12-cfr-1005", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "12 CFR 1005.11, read through the eCFR versioner API, confirms a 60 day consumer notice window running from the statement that first showed the error, a 10 business day investigation period extendable to 45 days if the institution provisionally credits the account within 10 business days and gives the consumer full use of the funds during the investigation, longer 20 and 90 business day periods for new accounts and certain point of sale or foreign initiated transfers, and the institution's right to debit back a provisional credit after notice once it determines no error occurred. 1005.2(b)(1) confirms Regulation E's account definition is limited to one established primarily for personal, family or household purposes. Together these confirm the statutory clock, the provisional and reversible nature of the credit, the longer clocks for new accounts and certain transfers, and the claim that a business account has no equivalent route." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:exc.reg-e-error-claim", "type": "enters", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.posted", "type": "precedes", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:state.return-dishonored", "id": "state.return-dishonored", "rail": "us-ach", "class": "LifecycleState", "name": "Return dishonored by the ODFI", "summary": "The ODFI has sent the return back to the receiving bank, which undoes the return and moves its value back toward the receiving side. It has 5 banking days from the return's own settlement date, not from the original entry's, and the grounds are narrow: the return arrived late, went to the wrong place, repeated a return already made, carried data that does not match the original entry, or claimed a request or an agreement the ODFI never gave. A returned federal payment is dishonoured where any of four fields of the original differ. The receiving bank has 2 banking days from here to answer; if it does not, the dishonour stands. An IAT never reaches this condition, because the process does not run for IAT at all.", "terminal": false, "money_moved": "yes", "visible_as": "nothing new for the Originator, whose payment has already failed; between the banks the value is moving back toward the receiving side", "relations": [ { "type": "precedes", "to": "us-ach:state.dishonor-contested", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.dishonor-window-5-banking-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-returns-can-be-sent-back-again", "note": "the grounds, and Treasury's four field test", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.iat-no-dishonored-returns", "note": "the entries that cannot enter this state", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.contest-window-2-banking-days", "note": "leaving the state", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted from the us-ach Rules this record is governed_by, every one of them already in the corpus. No document was opened for this record. No source Orca holds publishes a lifecycle state model for ACH, so which conditions are worth naming, and the order they run in, are Orca's. [Unverified] The dishonour window Rule and the Exception it governs already carry the grounds and the clock. What the state adds is that the value has moved a second time and that the payment is not finished.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "First LifecycleState slice, 2026-09-20. The state is Orca's grouping of Rules already in the corpus; no rule change is claimed and no date of its own is known.", "source_edition": "As the Rules this state is governed_by; no document was opened for this record.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "CBS Bank's Quick Reference Guide confirms that an ODFI must transmit a dishonored return entry within five banking days after the settlement date of the returned entry, and that the dishonored return codes cover a misrouted return, a duplicate return, an untimely return, a field error and a return the ODFI never requested or agreed to accept, supporting the window and grounds this state names and their exclusion for IAT." }, { "source": "us-ach:src.treasury-green-book-2025-03", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "The Treasury Green Book confirms that a federal payment return is dishonored where any of four named fields, the original entry trace number, the effective entry date, the amount and the individual identification number, differs from the original payment, supporting the claim that a returned federal payment is dishonored where the original data does not match." }, { "source": "us-ach:src.nacha-iat-faqs-web", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Nacha's International ACH Transactions FAQ page confirms that automated dishonored returns are not supported for the IAT SEC code and that any dishonor request must be handled outside the ACH Network, supporting the claim that an IAT entry never reaches this state." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:exc.dishonored-return", "type": "enters", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.returned", "type": "precedes", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:state.returned", "id": "state.returned", "rail": "us-ach", "class": "LifecycleState", "name": "Returned", "summary": "The entry has gone back toward the ODFI carrying a return reason code, and the operator has settled the return like any other item, so value has moved in the opposite direction. Who sent it and on what clock depends on the reason. The receiving bank has 2 banking days from the original entry's settlement date for most reasons and up to 60 calendar days for an unauthorised debit to a consumer account, which it may only return on a written statement from the Receiver. The operator returns at processing what fails its own edits. A Gateway and a federal agency have reasons reserved to them. Returned is not the end: the originating side can dishonour the return, a debit that came back for want of funds may be presented twice more, and one the Receiver says was never authorised may not be sent again at all without a new authorisation.", "terminal": false, "money_moved": "yes", "visible_as": "the Originator's app shows the payment failed and names the return reason code; the Receiver sees the entry taken off the account again", "relations": [ { "type": "precedes", "to": "us-ach:state.return-dishonored", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-the-mechanism", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-how-a-return-settles", "note": "why money_moved is yes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-2-banking-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-60-calendar-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.written-statement-of-unauthorized-debit", "note": "what the 60 day route needs before the state can be entered", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-operator-reject", "note": "the operator's own route into this state", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-returns-can-be-sent-back-again", "note": "leaving the state", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.reinitiation-after-funds-return", "note": "what may follow a funds return, as a new entry", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.no-reinitiation-without-new-authorization", "note": "what may not follow an unauthorised return", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted from the us-ach Rules this record is governed_by, every one of them already in the corpus. No document was opened for this record. No source Orca holds publishes a lifecycle state model for ACH, so which conditions are worth naming, and the order they run in, are Orca's. [Unverified] The return Exception and its window Rules are already linked to the 90 us-ach reason codes; this record is the condition those Rules leave the payment in, and adds no window of its own.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "First LifecycleState slice, 2026-09-20. The state is Orca's grouping of Rules already in the corpus; no rule change is claimed and no date of its own is known.", "source_edition": "As the Rules this state is governed_by; no document was opened for this record.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Operating Circular 4 confirms that a receiving bank may return a debit or credit item to a Reserve Bank by the deadline the FedACH Processing Schedule sets, and that on the settlement date the Reserve Banks debit or credit the sending and receiving banks' settlement accounts for a returned item just as for any other item, supporting the claim that the operator settles a return like any other item and that value has moved in the opposite direction." }, { "source": "us-ach:src.fedach-processing-schedule-2022-09-12", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "The FedACH Processing Schedule's Electronic Return Items table confirms submission deadlines and settlement times for returns, supporting how a return settles." }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "CBS Bank's Quick Reference Guide confirms a general 2 banking day return deadline and an extended 60 calendar day deadline for an unauthorized consumer debit return, supporting the two return windows this state names." }, { "source": "us-ach:src.treasury-green-book-2025-03", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "The Treasury Green Book's Dishonored Returns section confirms that a federal disbursing office dishonors a return if any of four named fields, the original entry trace number, the effective entry date, the payment amount and the individual identification number, do not match the original payment, supporting the claim that returns can be sent back again." }, { "source": "us-ach:src.bmo-ach-return-reason-codes-2025-05", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "BMO's ACH Return Reason Codes guide confirms that codes such as R13, R18, R19, R26 and R28 are applied by the ACH Operator itself during processing rather than by the RDFI, supporting the claim that the operator returns at processing what fails its own edits." }, { "source": "us-ach:src.nacha-differentiating-unauthorized-return-reasons", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Nacha's page differentiating unauthorized return reasons confirms that an RDFI must obtain the Receiver's Written Statement of Unauthorized Debit before returning an entry as unauthorized, supporting the claim that the 60 day route needs a written statement before this state can be entered on that ground." }, { "source": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Popular Bank's ACH Rules Awareness Guide return reason code table confirms that an entry returned for insufficient funds under code R01 may be resubmitted by the Originator up to two additional times without new authorization within 180 days of the original settlement date, and that codes such as R03, R04 and R05 bar further transactions until new bank account information and authorization are obtained, supporting the claims that a debit returned for want of funds may be presented twice more and that one the Receiver says was never authorized may not be reinitiated without a new authorization." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:exc.return", "type": "enters", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.awaiting-settlement", "type": "precedes", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.funds-available", "type": "precedes", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.posted", "type": "precedes", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.recredited-under-regulation-e", "type": "precedes", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:state.settled", "type": "precedes", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:state.sent-to-the-operator", "id": "state.sent-to-the-operator", "rail": "us-ach", "class": "LifecycleState", "name": "Sent to the ACH Operator", "summary": "Every release step is done and the file has gone to an ACH Operator. The sending side can no longer amend the entry or take it back: what is left are the routes the rules themselves give, which are a fresh reversing entry for one of a short list of errors, or asking the receiving bank to send the entry back and hoping it agrees. Neither is a cancellation, and neither is owed. The operator has not yet said whether it will carry the entry.", "terminal": false, "money_moved": "no", "visible_as": "still pending in the Originator's app; the ODFI can see the file it transmitted, and no account on either side has moved", "relations": [ { "type": "precedes", "to": "us-ach:state.held-at-the-operator", "note": "where the operator queries the file or the ODFI's own monitoring stops a batch", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "precedes", "to": "us-ach:state.awaiting-settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.finality-no-recall-by-the-sender-once-the-file-has-gone", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.hours-release-not-transmission-is-what-counts", "note": "what counts as having sent the file", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.finality-reversals-exist-and-they-are-new-entries", "note": "one way out, and it is a new entry", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.recall-asking-rather-than-reversing", "note": "the other way out, and the receiving bank may refuse", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted from the us-ach Rules this record is governed_by, every one of them already in the corpus. No document was opened for this record. No source Orca holds publishes a lifecycle state model for ACH, so which conditions are worth naming, and the order they run in, are Orca's. [Unverified] The Rules state what the sending side may and may not do once the file has gone, which is what makes this a condition of its own rather than part of origination.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "First LifecycleState slice, 2026-09-20. The state is Orca's grouping of Rules already in the corpus; no rule change is claimed and no date of its own is known.", "source_edition": "As the Rules this state is governed_by; no document was opened for this record.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Operating Circular 4 confirms that a sending bank or prior party may not amend or revoke an item once it has been sent to a Reserve Bank, and that release for processing rather than transmission is what fixes that moment, supporting the claim that the sending side can no longer amend or take back the entry once this state is entered." }, { "source": "us-ach:src.nacha-reversals-and-enforcement", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Nacha's Reversals and Enforcement rule page confirms that a reversal must be transmitted as a freshly originated entry with matching Company ID, SEC code and amount fields, supporting the claim that a reversing entry is one way out of this state and that it is a new entry rather than an undoing of the original." }, { "source": "us-ach:src.popular-bank-ach-rules-awareness-guide-2025-04-02", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Popular Bank's ACH Rules Awareness Guide confirms that a return requested under code R06 depends on the RDFI's agreement, with the ODFI required to indemnify the RDFI if it agrees to return the entry, supporting the claim that asking the receiving bank to send the entry back is a request the receiving bank may or may not grant rather than a guaranteed recall." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:state.originated", "type": "precedes", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:state.settled", "id": "state.settled", "rail": "us-ach", "class": "LifecycleState", "name": "Settled at the Reserve Banks", "summary": "At the settlement time for the entry's window, the Reserve Bank holding each bank's settlement account has debited or credited it for the amount, one side against the other. Value has moved between the banks, and it moved in central bank money, so it can only have happened while the Federal Reserve's settlement service was open. What that is worth differs by direction. On a credit the receiving bank's credit is final and countable as reserves from that time. On a debit the originating side has credit rather than collected funds, and a whole window of debit settlements can be taken back the next morning. Settled is not safe either way: this settlement date is the date the return clocks are counted from, so the entry can still come back.", "terminal": false, "money_moved": "yes", "visible_as": "the two banks see the amount on their Reserve Bank settlement accounts; the Receiver's own app may still show the payment as pending until the bank posts it", "relations": [ { "type": "precedes", "to": "us-ach:state.settlement-unwound", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "precedes", "to": "us-ach:state.posted", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "precedes", "to": "us-ach:state.returned", "note": "a return settles in the opposite direction, and its window is counted from this settlement date", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.settlement-what-settlement-is", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.settlement-the-settlement-asset-and-its-hours", "note": "when the state can be entered at all", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.finality-the-moment-settlement-is-final-for-a-credit", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.settlement-credit-given-for-a-debit-is-not-the-same-as", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.finality-settlement-can-be-unwound-the-next-morning", "note": "leaving the state backwards", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.finality-the-practical-window-returns-run-in-days-not", "note": "the clocks that start here", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted from the us-ach Rules this record is governed_by, every one of them already in the corpus. No document was opened for this record. No source Orca holds publishes a lifecycle state model for ACH, so which conditions are worth naming, and the order they run in, are Orca's. [Unverified] Six Rules state the mechanics, the hours, the finality of a credit, the weaker position of a debit and the two ways value can leave again. The state adds only that they are one condition of one payment.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "First LifecycleState slice, 2026-09-20. The state is Orca's grouping of Rules already in the corpus; no rule change is claimed and no date of its own is known.", "source_edition": "As the Rules this state is governed_by; no document was opened for this record.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Operating Circular 4 confirms that at settlement time the Reserve Bank holding each bank's settlement account debits or credits it for the item's amount, that credit given for a debit item is available from the settlement date subject to the Reserve Bank's discretion, that credit given for a credit item is final and available at settlement, and that a Reserve Bank may reverse the debits and credits for a whole settlement window's debit items the following morning, supporting this state's claims about what settling means, its finality for a credit, its weaker position for a debit, and its precedes link to settlement being unwound." }, { "source": "us-ach:src.fedach-processing-schedule-2022-09-12", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "The FedACH Processing Schedule confirms the settlement clock times for each submission window and points settlement to the Federal Reserve Policy on Payment System Risk, supporting the claim that settlement can only happen while the Federal Reserve's settlement service is open." }, { "source": "us-ach:src.nacha-abcs-of-ach", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Nacha's ABCs of ACH page confirms that the ACH Network settles when the Federal Reserve's settlement service is open and that a Receiver's own bank may advance funds before settlement occurs, supporting the claim that a Receiver's app may still show a payment as pending here even though the banks themselves already see the amount on their settlement accounts." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:state.awaiting-settlement", "type": "precedes", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:state.settlement-unwound", "id": "state.settlement-unwound", "rail": "us-ach", "class": "LifecycleState", "name": "Settlement unwound", "summary": "A Reserve Bank did not collect funds for the debit entries that settled in a window on the previous banking day, and has taken the debits and credits for every debit entry in that window back off the banks' settlement accounts. The value that moved at settlement has been removed, so nothing has been transferred after all. This is a whole window at once and not this entry's own failing, and the discretion behind it is the Reserve Bank's own, not a warranty one bank owes another. Orca holds no Rule saying what becomes of an entry whose settlement window has been unwound, so this record names no state after it.", "terminal": false, "money_moved": "no", "visible_as": "the banks are told on the day, by 4:00 pm Eastern; a Receiver may see a credit taken back off the account with no failure of its own to explain it", "relations": [ { "type": "governed_by", "to": "us-ach:rule.finality-settlement-can-be-unwound-the-next-morning", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.settlement-credit-given-for-a-debit-is-not-the-same-as", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.liability-settlement-risk-sits-with-the-reserve-banks", "note": "whose discretion this is", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Drafted from the us-ach Rules this record is governed_by, every one of them already in the corpus. No document was opened for this record. No source Orca holds publishes a lifecycle state model for ACH, so which conditions are worth naming, and the order they run in, are Orca's. [Unverified] terminal is false because nothing in the corpus says the entry is finished, and the record names no successor because nothing in the corpus says what follows. That gap is the record's own statement, not an omission.", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "First LifecycleState slice, 2026-09-20. The state is Orca's grouping of Rules already in the corpus; no rule change is claimed and no date of its own is known.", "source_edition": "As the Rules this state is governed_by; no document was opened for this record.", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.frb-operating-circular-4-2026-01-05", "checked_on": "2026-09-21", "checked_by": "validator-sonnet-2026-09-21", "notes": "Operating Circular 4 paragraph 11.1(b) confirms that if a Reserve Bank has not received actually and finally collected funds by noon Eastern for all debit items that settled on the immediately prior banking day, the Reserve Banks holding the sending and receiving banks' settlement accounts may reverse the debits and credits for every debit item that settled in that window, and that they notify the banks of the action by no later than 4:00pm Eastern on the day it is taken. This supports the trigger, the whole window scope, the visible_as notification time, and the record's own statement that no successor state is named because no rule in the corpus addresses what follows." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:state.settled", "type": "precedes", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:txn.arc", "id": "txn.arc", "rail": "us-ach", "class": "TransactionType", "name": "Accounts Receivable Entry (ARC)", "summary": "A one-time debit converted from a check the payer mailed or dropped off to the Originator.", "sec_code": "ARC", "directions": [ "debit" ], "account_types": [ "any" ], "value": true, "relations": [], "basis": { "sources": "Written for the 2026-09 Orca Core migration from general knowledge of the US ACH network and the us-ach reason code records that name it; no source consulted for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nicolet-ach-quick-reference-guide", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-core-2026-09-19", "notes": "Confirms ARC is a check conversion entry used to convert a check received by mail, drop box, or in person for payment of a bill at a manned location, that it is a debit, and that it applies to consumer or corporate accounts." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R36", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R37", "type": "applies_to", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R38", "type": "applies_to", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R39", "type": "applies_to", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:txn.boc", "id": "txn.boc", "rail": "us-ach", "class": "TransactionType", "name": "Back Office Conversion Entry (BOC)", "summary": "A one-time debit converted in the back office from a check presented in person at a point of purchase or staffed payment location.", "sec_code": "BOC", "directions": [ "debit" ], "account_types": [ "any" ], "value": true, "relations": [], "basis": { "sources": "Written for the 2026-09 Orca Core migration from general knowledge of the US ACH network and the us-ach reason code records that name it; no source consulted for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nicolet-ach-quick-reference-guide", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-core-2026-09-19", "notes": "Confirms BOC is a check conversion entry used to convert a check presented at the point-of-sale or a manned bill payment location in the back office, that it is a debit, and that it applies to consumer or corporate accounts." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R36", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R37", "type": "applies_to", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R38", "type": "applies_to", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R39", "type": "applies_to", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:txn.ccd", "id": "txn.ccd", "rail": "us-ach", "class": "TransactionType", "name": "Corporate Credit or Debit Entry (CCD)", "summary": "A credit or debit between business accounts.", "sec_code": "CCD", "directions": [ "debit", "credit" ], "account_types": [ "non_consumer" ], "value": true, "relations": [], "basis": { "sources": "Written for the 2026-09 Orca Core migration from general knowledge of the US ACH network and the us-ach reason code records that name it; no source consulted for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nicolet-ach-quick-reference-guide", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-core-2026-09-19", "notes": "Confirms CCD covers corporate to corporate transactions, that both debits and credits are used for it, and that it is a corporate rather than consumer entry." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:mandate.corporate-debit-agreement", "type": "authorises", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.authorization-ccd-ctx", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-addenda-indicator-and-linking", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C14", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R05", "type": "applies_to", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R29", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R31", "type": "applies_to", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:txn.cie", "id": "txn.cie", "rail": "us-ach", "class": "TransactionType", "name": "Customer Initiated Entry (CIE)", "summary": "A credit a consumer starts through their own bank, typically a bill payment.", "sec_code": "CIE", "directions": [ "credit" ], "account_types": [ "consumer" ], "value": true, "relations": [], "basis": { "sources": "Written for the 2026-09 Orca Core migration from general knowledge of the US ACH network and the us-ach reason code records that name it; no source consulted for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.format-cie-mte-name-and-identification", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R22", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:txn.cor", "id": "txn.cor", "rail": "us-ach", "class": "TransactionType", "name": "Notification of change (COR)", "summary": "The Standard Entry Class code a Notification of Change travels under. It carries no money: it tells the ODFI and Originator which data on a posted entry to change for future entries.", "sec_code": "COR", "directions": [ "debit", "credit" ], "account_types": [ "any" ], "value": false, "relations": [ { "type": "sourced_from", "to": "us-ach:src.treasury-green-book-2025-03", "section": "Notification of Change chapter, section A", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-same-day-ach-faq", "section": "answer on NOCs and the Same Day Entry Fee", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraph 2.1(j)", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Treasury Green Book (2025-03) names COR as the SEC code of an NOC; the Federal Reserve Same Day ACH FAQ calls NOCs entries bearing COR; Operating Circular 4 counts NOCs among nonvalue messages. Read 2026-09-19. directions reads that an NOC may relate to a debit or a credit entry. [Inference]", "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": "us-ach:src.treasury-green-book-2025-03", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-core-2026-09-19", "notes": "Confirms COR is Nacha's Standard Entry Class code name for a Notification of Change, used by a financial institution to correct or change account information rather than to move money." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.noc-corrected-data-layout", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.noc-same-day-and-fee", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C01", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C02", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C03", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C05", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C06", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C07", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C08", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C09", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C13", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C14", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C61", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C62", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C63", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C64", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C65", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C66", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C67", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C68", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C69", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:txn.ctx", "id": "txn.ctx", "rail": "us-ach", "class": "TransactionType", "name": "Corporate Trade Exchange (CTX)", "summary": "A business to business credit or debit that can carry long structured remittance data.", "sec_code": "CTX", "directions": [ "debit", "credit" ], "account_types": [ "non_consumer" ], "value": true, "relations": [], "basis": { "sources": "Written for the 2026-09 Orca Core migration from general knowledge of the US ACH network and the us-ach reason code records that name it; no source consulted for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nicolet-ach-quick-reference-guide", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-core-2026-09-19", "notes": "Confirms CTX covers corporate to corporate transactions with payment related remittance information, that both debits and credits are used for it, and that it is a corporate rather than consumer entry." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:mandate.corporate-debit-agreement", "type": "authorises", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.authorization-ccd-ctx", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-addenda-indicator-and-linking", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-ctx-return", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R05", "type": "applies_to", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R29", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R31", "type": "applies_to", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:txn.enr", "id": "txn.enr", "rail": "us-ach", "class": "TransactionType", "name": "Automated Enrollment Entry (ENR)", "summary": "A zero-dollar entry a financial institution sends to a federal agency to enroll its customer's account for federal benefit credits. No money moves; credit is the direction of the payments it enrolls for. [Inference]", "sec_code": "ENR", "directions": [ "credit" ], "account_types": [ "any" ], "value": false, "relations": [], "basis": { "sources": "Written for the 2026-09 Orca Core migration from general knowledge of the US ACH network and the us-ach reason code records that name it; no source consulted for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.treasury-green-book-2025-03", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-core-2026-09-19", "notes": "Confirms an ENR entry is a non-monetary entry a financial institution sends through the ACH network to a federal government benefit agency to enroll a customer's account for Direct Deposit benefit payments." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.format-addenda-indicator-and-linking", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-enr-entry-codes", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-transaction-codes", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R40", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R41", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R42", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R43", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R44", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R45", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R46", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R47", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:txn.iat", "id": "txn.iat", "rail": "us-ach", "class": "TransactionType", "name": "International ACH Transaction (IAT)", "summary": "An entry that is the US ACH leg of a payment that crosses the border, one code for consumer and business accounts alike. Since 2026-09-18 the test is whether a financial agency abroad holds an account the funds leave, pass through or reach, or collects or pays out the funds. It is never eligible for same day settlement.", "sec_code": "IAT", "directions": [ "debit", "credit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "us-ach:src.frb-operating-circular-4-2026-01-05", "section": "paragraph 3.3(b)", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-same-day-ach-limit-10-million", "section": "which states IAT stays ineligible", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-definition-of-iat-entries", "section": "Details: Article Eight, Section 8.55, effective 2026-09-18", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "sourced_from", "to": "us-ach:src.nacha-iat-faqs-web", "section": "General: consumer versus corporate IAT", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Written for the 2026-09 Orca Core migration; summary revised 2026-09-19 from Nacha's Definition of IAT Entries page and IAT FAQ web page, read that day. Same day exclusion from Operating Circular 4 paragraph 3.3(b) and Nacha's $10 million page. directions and account_types rest on the Nacha IAT FAQs (debits and credits, consumer and corporate).", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "IAT since 2009-09-18; its definition was replaced on 2026-09-18 (see us-ach:rule.iat-definition).", "source_edition": "Operating Circular 4, effective 2026-01-05; Nacha public rule pages read 2026-09-17 and 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-definition-of-iat-entries", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-core-2026-09-19", "notes": "Confirms the Section 8.55 definition effective September 18, 2026, that an IAT is the US ACH leg of an international payment transaction where a financial agency outside the US holds, transits, or delivers the funds or sends or receives them through a facility of a financial agency located outside the US, and that an IAT entry cannot be a Same Day Entry." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.iat-addenda-structure", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-contact-registry-from-2027", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-date-of-birth-field-from-2027", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-definition", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-fedglobal-service-scope", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-foreign-exchange-fields", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-gateway-agreement-with-odfi", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-gateway-inbound-debit-limits", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-gateway-only-return-codes", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-gateway-operator-defined", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-no-dishonored-returns", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-notifications-of-change", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-ofac-hold-before-posting", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-ofac-screening-duties", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-ofac-screening-indicators", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-one-code-consumer-and-business", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-party-information-every-entry", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-prenotes", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-rdfi-must-accept", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-replaced-cbr-and-pbr", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-return-addenda", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-return-amount-may-differ", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-return-timeframes", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-reversal-best-effort", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-separate-file-option", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-us-jurisdiction-is-domestic", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.messages-the-travel-rule-threshold-and-what-an-iat-carries", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.participants-gateway-screening-does-not-move-the-duty", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C08", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C14", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R80", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R81", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R82", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R83", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R84", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:txn.micro-entry", "id": "txn.micro-entry", "rail": "us-ach", "class": "TransactionType", "name": "Micro-entry (account verification)", "summary": "A credit of less than $1, with any offsetting debits, sent to verify a Receiver's account or access to it, described ACCTVERIFY.", "sec_code": null, "directions": [ "credit", "debit" ], "account_types": [ "any" ], "value": true, "relations": [ { "type": "sourced_from", "to": "us-ach:src.nacha-micro-entries-phase-1", "section": "Details; read 2026-09-19", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Nacha's public Micro-Entries (Phase 1) page, read 2026-09-19. sec_code is null because the page ties micro-entries to a purpose and a description, not to one SEC code; account_types any is Orca's reading. [Inference]", "confidence": "medium" }, "currency": { "effective_since": "2022-09-16", "effective_to": null, "effective_note": "Defined by the Micro-Entries rule effective 2022-09-16.", "source_edition": "Nacha public rule page read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nacha-micro-entries-phase-1", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-core-2026-09-19", "notes": "Confirms Micro-Entries are defined as ACH credits of less than one dollar plus any offsetting ACH debits, used to verify a Receiver's account, and that the rule requires the Company Entry Description ACCTVERIFY." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.micro-entries-amounts-and-timing", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.micro-entries-definition-and-labels", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.micro-entries-fraud-monitoring", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.micro-entries-receiver-confirmation", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.practice-instant-verification-and-micro-deposits", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.web-validation-prenote-and-micro-entry-results", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:txn.mte", "id": "txn.mte", "rail": "us-ach", "class": "TransactionType", "name": "Machine Transfer Entry (MTE)", "summary": "A transfer a consumer makes at an ATM or similar terminal.", "sec_code": "MTE", "directions": [ "debit", "credit" ], "account_types": [ "consumer" ], "value": true, "relations": [], "basis": { "sources": "Written for the 2026-09 Orca Core migration from general knowledge of the US ACH network and the us-ach reason code records that name it; no source consulted for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.moov-ach-file-structure", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-core-2026-09-19", "notes": "Confirms a Machine Transfer Entry supports the clearing of transactions from automated teller machines." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.format-cie-mte-name-and-identification", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R22", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:txn.pop", "id": "txn.pop", "rail": "us-ach", "class": "TransactionType", "name": "Point-of-Purchase Entry (POP)", "summary": "A one-time debit converted from a check at the point of purchase, with the check handed back to the payer.", "sec_code": "POP", "directions": [ "debit" ], "account_types": [ "any" ], "value": true, "relations": [], "basis": { "sources": "Written for the 2026-09 Orca Core migration from general knowledge of the US ACH network and the us-ach reason code records that name it; no source consulted for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nicolet-ach-quick-reference-guide", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-core-2026-09-19", "notes": "Confirms POP is a check conversion entry used to convert a check received at the point of purchase or a manned bill payment location, that it is a debit, and that it applies to consumer or corporate accounts." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R36", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R37", "type": "applies_to", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R39", "type": "applies_to", "status": "corroborated", "effective_status": "corroborated" } ] }, { "uid": "us-ach:txn.ppd", "id": "txn.ppd", "rail": "us-ach", "class": "TransactionType", "name": "Prearranged Payment and Deposit Entry (PPD)", "summary": "A credit or debit to a consumer account under a single or standing authorization, such as payroll or a recurring bill.", "sec_code": "PPD", "directions": [ "debit", "credit" ], "account_types": [ "consumer" ], "value": true, "relations": [], "basis": { "sources": "Written for the 2026-09 Orca Core migration from general knowledge of the US ACH network and the us-ach reason code records that name it; no source consulted for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nicolet-ach-quick-reference-guide", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-core-2026-09-19", "notes": "Confirms PPD is a credit or debit entry initiated by an organization to a consumer account based on a standing or single entry authorization, with payroll and bill payment given as examples." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:mandate.consumer-debit-authorization", "type": "authorises", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.authorization-general-requirements", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.authorization-ppd", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-addenda-indicator-and-linking", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C14", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:txn.prenote", "id": "txn.prenote", "rail": "us-ach", "class": "TransactionType", "name": "Prenotification (prenote)", "summary": "A zero dollar entry an Originator may send ahead of the first live entry so the RDFI can check the routing and account number; it moves no money and uses its own transaction codes (23, 28, 33, 38, 53).", "sec_code": null, "directions": [ "debit", "credit" ], "account_types": [ "any" ], "value": false, "relations": [ { "type": "sourced_from", "to": "us-ach:src.nicolet-ach-quick-reference-guide", "section": "Prenotification (Pre-note); Transaction Codes", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "basis": { "sources": "Nicolet National Bank's Originator guide, read 2026-09-19. sec_code is null because a prenote is sent under the SEC code of the live entries it precedes. [Inference]", "confidence": "medium" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Drafted on 2026-09-19; no rule change identified.", "source_edition": "Bank guide, undated, read 2026-09-19", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nicolet-ach-quick-reference-guide", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-core-2026-09-19", "notes": "Confirms a prenotification is a zero dollar entry that precedes the first live entry to verify account information, and lists transaction codes 23, 28, 33, 38 and 53 for prenotification." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.format-transaction-codes", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.prenote-optional-zero-dollar-entry", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.prenote-response-deadline-and-originator-action", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.prenote-wait-before-live-entries", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.web-validation-prenote-and-micro-entry-results", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:txn.rck", "id": "txn.rck", "rail": "us-ach", "class": "TransactionType", "name": "Re-presented Check Entry (RCK)", "summary": "A debit that re-presents a paper check first returned for insufficient or uncollected funds.", "sec_code": "RCK", "directions": [ "debit" ], "account_types": [ "consumer" ], "value": true, "relations": [], "basis": { "sources": "Written for the 2026-09 Orca Core migration from general knowledge of the US ACH network and the us-ach reason code records that name it; no source consulted for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nicolet-ach-quick-reference-guide", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-core-2026-09-19", "notes": "Confirms RCK is a check conversion entry used to collect funds through the ACH network for a check returned for insufficient or uncollected funds, that it is a debit, and that it applies to consumer accounts." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.same-day-ineligible-entry-settles-next-day", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R36", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R50", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R51", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R52", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R53", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:txn.tel", "id": "txn.tel", "rail": "us-ach", "class": "TransactionType", "name": "Telephone-Initiated Entry (TEL)", "summary": "A consumer debit authorized orally over the telephone.", "sec_code": "TEL", "directions": [ "debit" ], "account_types": [ "consumer" ], "value": true, "relations": [], "basis": { "sources": "Written for the 2026-09 Orca Core migration from general knowledge of the US ACH network and the us-ach reason code records that name it; no source consulted for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.nicolet-ach-quick-reference-guide", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-core-2026-09-19", "notes": "Confirms TEL is an entry initiated pursuant to an oral authorization obtained over the telephone, that it is a debit, and that it applies to consumer accounts." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:mandate.consumer-debit-authorization", "type": "authorises", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:mandate.tel-debit-authorization", "type": "authorises", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.authorization-general-requirements", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.authorization-tel", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-addenda-indicator-and-linking", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R36", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:txn.trc", "id": "txn.trc", "rail": "us-ach", "class": "TransactionType", "name": "Check Truncation Entry (TRC)", "summary": "A debit carrying a check truncated under a check truncation program.", "sec_code": "TRC", "directions": [ "debit" ], "account_types": [ "any" ], "value": true, "relations": [], "basis": { "sources": "Written for the 2026-09 Orca Core migration from general knowledge of the US ACH network and the us-ach reason code records that name it; no source consulted for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.moov-ach-file-structure", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-core-2026-09-19", "notes": "Confirms TRC identifies a debit entry of a truncated check under a check truncation program." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R30", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:txn.trx", "id": "txn.trx", "rail": "us-ach", "class": "TransactionType", "name": "Check Truncation Entries Exchange (TRX)", "summary": "A batch of truncated checks exchanged as entries under a check truncation program.", "sec_code": "TRX", "directions": [ "debit" ], "account_types": [ "any" ], "value": true, "relations": [], "basis": { "sources": "Written for the 2026-09 Orca Core migration from general knowledge of the US ACH network and the us-ach reason code records that name it; no source consulted for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.moov-ach-file-structure", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-core-2026-09-19", "notes": "Confirms TRX identifies a debit entry of multiple truncated checks exchanged together under a check truncation program." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R30", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:txn.web", "id": "txn.web", "rail": "us-ach", "class": "TransactionType", "name": "Internet-Initiated or Mobile Entry (WEB)", "summary": "A consumer debit authorized over the internet or a mobile device, or a person to person credit.", "sec_code": "WEB", "directions": [ "debit", "credit" ], "account_types": [ "consumer" ], "value": true, "relations": [ { "type": "sourced_from", "to": "us-ach:src.tompkins-originating-ach-quick-reference", "section": "Originating WEB Entries: debit and credit WEB entries", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "basis": { "sources": "Written for the 2026-09 Orca Core migration from general knowledge of the US ACH network and the us-ach reason code records that name it; no source consulted for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "draft", "superseded_by": null, "corroboration": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:mandate.consumer-debit-authorization", "type": "authorises", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:mandate.web-debit-authorization", "type": "authorises", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.authorization-general-requirements", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.authorization-web", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-addenda-indicator-and-linking", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.web-debit-account-validation", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.web-validation-after-noc", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.web-validation-commercially-reasonable", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.web-validation-existing-accounts", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.web-validation-methods", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.web-validation-prenote-and-micro-entry-results", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.web-validation-what-it-confirms", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:txn.xck", "id": "txn.xck", "rail": "us-ach", "class": "TransactionType", "name": "Destroyed Check Entry (XCK)", "summary": "A debit for an eligible check that was destroyed or lost before it could be collected.", "sec_code": "XCK", "directions": [ "debit" ], "account_types": [ "any" ], "value": true, "relations": [], "basis": { "sources": "Written for the 2026-09 Orca Core migration from general knowledge of the US ACH network and the us-ach reason code records that name it; no source consulted for this record. [Unverified]", "confidence": "low" }, "currency": { "effective_since": "Long-standing", "effective_to": null, "effective_note": "Written by the 2026-09 Orca Core migration; no rule change identified.", "source_edition": "Nacha Operating Rules not consulted; the record rests on the sources listed in its relations and basis", "last_verified": null, "verified_by": null, "status": "corroborated", "superseded_by": null, "corroboration": [ { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "checked_on": "2026-09-19", "checked_by": "validator-us-ach-core-2026-09-19", "notes": "Confirms XCK covers a destroyed check entry, that credit entries are not permitted for XCK so it is a debit, and that it applies to consumer or non-consumer accounts." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.same-day-ineligible-entry-settles-next-day", "type": "applies_to", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R33", "type": "applies_to", "status": "corroborated", "effective_status": "corroborated" }, { "from": "us-ach:R36", "type": "applies_to", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:C01", "id": "C01", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [], "text": "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" }, "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.", "relations": [ { "type": "raised_in", "to": "us-ach:exc.notification-of-change", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-window-2-banking-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-originator-applies-the-change", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-rdfi-warrants-the-corrected-data", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-corrected-data-layout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.cor", "note": "The code travels in a COR entry.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R03", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R04", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:C03", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C06", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:C02", "id": "C02", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [], "text": "the corporate and consumer SEC codes CBS Bank lists for it (CCD, CIE, CTX, MTE, PPD, POS, SHR), CBR, PBR and IAT" }, "caveat": null, "relations": [ { "type": "raised_in", "to": "us-ach:exc.notification-of-change", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-window-2-banking-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-originator-applies-the-change", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-rdfi-warrants-the-corrected-data", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-corrected-data-layout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.cor", "note": "The code travels in a COR entry.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:C03", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:C03", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:C03", "id": "C03", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [ "us-ach:txn.iat" ], "text": "the corporate and consumer SEC codes CBS Bank lists for it (CCD, CIE, CTX, MTE, PPD, POS, SHR)" }, "caveat": "Not used for IAT, where the field is too short to carry both values.", "relations": [ { "type": "raised_in", "to": "us-ach:exc.notification-of-change", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-window-2-banking-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-originator-applies-the-change", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-rdfi-warrants-the-corrected-data", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-corrected-data-layout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.cor", "note": "The code travels in a COR entry.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:C02", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:C01", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:C02", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C07", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:C05", "id": "C05", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [], "text": "CCD, CTX, MTE, PPD, POS, SHR and IAT, per CBS Bank" }, "caveat": null, "relations": [ { "type": "raised_in", "to": "us-ach:exc.notification-of-change", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-window-2-banking-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-originator-applies-the-change", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-rdfi-warrants-the-corrected-data", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-corrected-data-layout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.cor", "note": "The code travels in a COR entry.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:C06", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.participants-a-wrong-account-type-code-is-corrected-not-refused", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C06", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:C06", "id": "C06", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [ "us-ach:txn.iat" ], "text": "the corporate and consumer SEC codes CBS Bank lists for it (CCD, CIE, CTX, MTE, PPD, POS, SHR), CBR and PBR" }, "caveat": "Not used for outbound IAT entries.", "relations": [ { "type": "raised_in", "to": "us-ach:exc.notification-of-change", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-window-2-banking-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-originator-applies-the-change", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-rdfi-warrants-the-corrected-data", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-corrected-data-layout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.cor", "note": "The code travels in a COR entry.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:C01", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:C05", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:C05", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C07", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:C07", "id": "C07", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [ "us-ach:txn.iat" ], "text": "the corporate and consumer SEC codes CBS Bank lists for it (CCD, CIE, CTX, MTE, PPD, POS, SHR)" }, "caveat": "Not used for IAT.", "relations": [ { "type": "raised_in", "to": "us-ach:exc.notification-of-change", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-window-2-banking-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-originator-applies-the-change", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-rdfi-warrants-the-corrected-data", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-corrected-data-layout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.cor", "note": "The code travels in a COR entry.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:C03", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:C06", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:C08", "id": "C08", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [ "us-ach:txn.iat" ], "excludes": [], "text": "IAT only" }, "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.", "relations": [ { "type": "raised_in", "to": "us-ach:exc.notification-of-change", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-window-2-banking-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-originator-applies-the-change", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-rdfi-warrants-the-corrected-data", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-corrected-data-layout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.cor", "note": "The code travels in a COR entry.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:C09", "id": "C09", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [], "text": "CIE, IAT, MTE, POS and SHR, per CBS Bank" }, "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.", "relations": [ { "type": "raised_in", "to": "us-ach:exc.notification-of-change", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-window-2-banking-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-originator-applies-the-change", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-rdfi-warrants-the-corrected-data", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-corrected-data-layout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.cor", "note": "The code travels in a COR entry.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:C13", "id": "C13", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [], "text": "the corporate and consumer SEC codes CBS Bank lists for it (CCD, CIE, CTX, MTE, PPD, POS, SHR) and IAT" }, "caveat": null, "relations": [ { "type": "raised_in", "to": "us-ach:exc.notification-of-change", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-window-2-banking-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-originator-applies-the-change", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-rdfi-warrants-the-corrected-data", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-corrected-data-layout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.cor", "note": "The code travels in a COR entry.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:C14", "id": "C14", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [ "us-ach:txn.ccd", "us-ach:txn.ppd" ], "excludes": [], "text": "CCD and PPD entries that turn out to be outbound international" }, "caveat": "Only a Gateway may use C14. IAT coding rules belong to the IAT records.", "relations": [ { "type": "raised_in", "to": "us-ach:exc.notification-of-change", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.gateway", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-window-2-banking-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.noc-originator-applies-the-change", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.cor", "note": "The code travels in a COR entry.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.ccd", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.ppd", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:txn.iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:C61", "id": "C61", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Nothing to retry: no money moved. As the RDFI, check the original entry and decide whether to send a new, correct NOC. [Inference]" }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [], "text": "any NOC" }, "caveat": null, "relations": [ { "type": "raised_in", "to": "us-ach:exc.refused-notification-of-change", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.refused-noc-window-none-found", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.cor", "note": "The refusal travels in a COR entry.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:C62", "id": "C62", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Nothing to retry: no money moved. As the RDFI, check the original entry and decide whether to send a new, correct NOC. [Inference]" }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [], "text": "any NOC" }, "caveat": null, "relations": [ { "type": "raised_in", "to": "us-ach:exc.refused-notification-of-change", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.refused-noc-window-none-found", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.cor", "note": "The refusal travels in a COR entry.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:C63", "id": "C63", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Nothing to retry: no money moved. As the RDFI, check the original entry and decide whether to send a new, correct NOC. [Inference]" }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [], "text": "any NOC" }, "caveat": null, "relations": [ { "type": "raised_in", "to": "us-ach:exc.refused-notification-of-change", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.refused-noc-window-none-found", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.cor", "note": "The refusal travels in a COR entry.", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:C64", "id": "C64", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Nothing to retry: no money moved. As the RDFI, check the original entry and decide whether to send a new, correct NOC. [Inference]" }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [], "text": "any NOC" }, "caveat": null, "relations": [ { "type": "raised_in", "to": "us-ach:exc.refused-notification-of-change", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.refused-noc-window-none-found", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.cor", "note": "The refusal travels in a COR entry.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.noc-federal-agencies-accept-six-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:C65", "id": "C65", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Nothing to retry: no money moved. As the RDFI, check the original entry and decide whether to send a new, correct NOC. [Inference]" }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [], "text": "any NOC" }, "caveat": null, "relations": [ { "type": "raised_in", "to": "us-ach:exc.refused-notification-of-change", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.refused-noc-window-none-found", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.cor", "note": "The refusal travels in a COR entry.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.noc-corrected-data-layout", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.noc-federal-agencies-accept-six-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:C66", "id": "C66", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Nothing to retry: no money moved. As the RDFI, check the original entry and decide whether to send a new, correct NOC. [Inference]" }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [], "text": "any NOC" }, "caveat": null, "relations": [ { "type": "raised_in", "to": "us-ach:exc.refused-notification-of-change", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.refused-noc-window-none-found", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.cor", "note": "The refusal travels in a COR entry.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.noc-federal-agencies-accept-six-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:C67", "id": "C67", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Nothing to retry: no money moved. As the RDFI, check the original entry and decide whether to send a new, correct NOC. [Inference]" }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [], "text": "any NOC" }, "caveat": null, "relations": [ { "type": "raised_in", "to": "us-ach:exc.refused-notification-of-change", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.refused-noc-window-none-found", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.cor", "note": "The refusal travels in a COR entry.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.noc-federal-agencies-accept-six-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:C68", "id": "C68", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Nothing to retry: no money moved. As the RDFI, check the original entry and decide whether to send a new, correct NOC. [Inference]" }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [], "text": "any NOC" }, "caveat": null, "relations": [ { "type": "raised_in", "to": "us-ach:exc.refused-notification-of-change", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.refused-noc-window-none-found", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.cor", "note": "The refusal travels in a COR entry.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.noc-federal-agencies-accept-six-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:C69", "id": "C69", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Nothing to retry: no money moved. As the RDFI, check the original entry and decide whether to send a new, correct NOC. [Inference]" }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [], "text": "any NOC" }, "caveat": null, "relations": [ { "type": "raised_in", "to": "us-ach:exc.refused-notification-of-change", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.refused-noc-window-none-found", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.cor", "note": "The refusal travels in a COR entry.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.noc-federal-agencies-accept-six-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:R01", "id": "R01", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "debit", "account_type": "any", "transaction_types": [], "excludes": [], "text": "any debit" }, "caveat": null, "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-2-banking-days", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.reinitiation-after-funds-return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R09", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.fhb-ach-return-reason-codes", "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.consumer-law-a-returned-payment-fee-is-its-own-debit", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R09", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R02", "id": "R02", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [], "text": "any" }, "caveat": null, "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-2-banking-days", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.administrative-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R03", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R04", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.fhb-ach-return-reason-codes", "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R03", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R12", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R20", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R03", "id": "R03", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not retry with the same account data. Correct the number first, then originate as a new entry." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [], "text": "any" }, "caveat": null, "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-2-banking-days", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.administrative-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R04", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R02", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.fhb-ach-return-reason-codes", "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.participants-posting-rests-on-the-account-number", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:C01", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R02", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R04", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R12", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R17", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R43", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R04", "id": "R04", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not retry. A malformed number will fail the same edit every time." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [], "text": "any" }, "caveat": null, "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-2-banking-days", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.administrative-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R03", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.fhb-ach-return-reason-codes", "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:C01", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R02", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R03", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R17", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R43", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R05", "id": "R05", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "debit", "account_type": "consumer", "transaction_types": [ "us-ach:txn.ccd", "us-ach:txn.ctx" ], "excludes": [], "text": "CCD, CTX to a consumer account" }, "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.", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-60-calendar-days", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.written-statement-of-unauthorized-debit", "evidence": [ { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.no-reinitiation-without-new-authorization", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.unauthorized-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.ccd", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.ctx", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "concerns", "to": "us-ach:mandate.consumer-debit-authorization", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R07", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R10", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R29", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.fhb-ach-return-reason-codes", "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R10", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R29", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R06", "id": "R06", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [], "text": "any" }, "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]", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-odfi-request", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.request-for-return-indemnity", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R31", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.fhb-ach-return-reason-codes", "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R17", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R23", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R24", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R70", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R07", "id": "R07", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not retry. Authorization no longer exists. A new debit requires new authorization, obtained and documented fresh." }, "applies_to": { "direction": "debit", "account_type": "consumer", "transaction_types": [], "excludes": [], "text": "consumer debit" }, "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.", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-60-calendar-days", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.written-statement-of-unauthorized-debit", "evidence": [ { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.no-reinitiation-without-new-authorization", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.unauthorized-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "concerns", "to": "us-ach:mandate.consumer-debit-authorization", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R10", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R11", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R08", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.fhb-ach-return-reason-codes", "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R05", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R08", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R10", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R11", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R08", "id": "R08", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not retry this entry. Re-presenting against a live stop order produces another return and, if the receiver escalates, an unauthorized code instead." }, "applies_to": { "direction": "debit", "account_type": "any", "transaction_types": [], "excludes": [], "text": "any debit" }, "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.", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-2-banking-days", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R07", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.fhb-ach-return-reason-codes", "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R07", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R38", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R52", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R09", "id": "R09", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Retry permitted under the same terms as R01: two reinitiations, three presentments total, within 180 days, carrying RETRY PYMT in the Company Entry Description." }, "applies_to": { "direction": "debit", "account_type": "any", "transaction_types": [], "excludes": [], "text": "any debit" }, "caveat": null, "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-2-banking-days", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.reinitiation-after-funds-return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R01", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.fhb-ach-return-reason-codes", "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R01", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R10", "id": "R10", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "debit", "account_type": "consumer", "transaction_types": [], "excludes": [], "text": "consumer debit" }, "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.", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-60-calendar-days", "evidence": [ { "source": "us-ach:src.nacha-differentiating-unauthorized-return-reasons" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.written-statement-of-unauthorized-debit", "evidence": [ { "source": "us-ach:src.nacha-differentiating-unauthorized-return-reasons" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.no-reinitiation-without-new-authorization", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.unauthorized-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "concerns", "to": "us-ach:mandate.consumer-debit-authorization", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R11", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R07", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R29", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R05", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.nacha-differentiating-unauthorized-return-reasons", "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." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.participants-who-an-account-holder-asks-about-a-payment", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R05", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R07", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R11", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R29", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R39", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R51", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R11", "id": "R11", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "debit", "account_type": "consumer", "transaction_types": [], "excludes": [], "text": "consumer debit" }, "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.", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-60-calendar-days", "evidence": [ { "source": "us-ach:src.nacha-differentiating-unauthorized-return-reasons" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.written-statement-of-unauthorized-debit", "evidence": [ { "source": "us-ach:src.nacha-differentiating-unauthorized-return-reasons" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.r11-corrected-entry", "evidence": [ { "source": "us-ach:src.nacha-differentiating-unauthorized-return-reasons" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.unauthorized-return-rate-threshold", "effective_since": "2020-04-01", "evidence": [ { "source": "us-ach:src.nacha-differentiating-unauthorized-return-reasons" } ], "note": "The record's effective_note hedges that R11 joined the unauthorized rate on a later phased date; the 2026-09-17 check against Nacha's page found it counted from phase 1, 2020-04-01. Guides that leave R11 out of the rate, and the Nacha text that settles it, are in the source conflict register, corpus/conflicts.json, entry us-ach-r11-unauthorized-return-rate.", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "concerns", "to": "us-ach:mandate.consumer-debit-authorization", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R10", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R07", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.nacha-differentiating-unauthorized-return-reasons", "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." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R07", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R10", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R17", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R30", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R37", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R39", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R12", "id": "R12", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not resend to the same routing number. Obtain the new routing and account details, then originate a new entry." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [], "text": "any" }, "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.", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-2-banking-days", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R02", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R03", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.fhb-ach-return-reason-codes", "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R13", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R13", "id": "R13", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not resend to the same routing number. Obtain a valid ACH routing number and originate the entry again." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [], "text": "any" }, "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].", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.ach-operator", "evidence": [ { "source": "us-ach:src.bmo-ach-return-reason-codes-2025-05" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-operator-reject", "evidence": [ { "source": "us-ach:src.bmo-ach-return-reason-codes-2025-05" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R28", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R12", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.bmo-ach-return-reason-codes-2025-05", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R42", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R14", "id": "R14", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not resend. Future entries need a new payee arrangement or a different account." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [], "text": "any, most often benefit credits" }, "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]", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-2-banking-days", "evidence": [ { "source": "us-ach:src.modern-treasury-ach-return-code-reference" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.modern-treasury-ach-return-code-reference", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R15", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R46", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R15", "id": "R15", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Never retry. Any further entry needs authority from whoever now controls the account or the estate." }, "applies_to": { "direction": "any", "account_type": "consumer", "transaction_types": [], "excludes": [], "text": "consumer accounts" }, "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]", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-2-banking-days", "evidence": [ { "source": "us-ach:src.modern-treasury-ach-return-code-reference" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R14", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.modern-treasury-ach-return-code-reference", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:R16", "id": "R16", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not retry. The restriction persists until the imposing authority lifts it, on a timeline you cannot influence." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [], "text": "any" }, "caveat": null, "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-2-banking-days", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R90", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.fhb-ach-return-reason-codes", "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.iat-ofac-hold-before-posting", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R90", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R17", "id": "R17", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not retry until the reason in the addenda is resolved. Never resend after a QUESTIONABLE return without independently confirming the counterparty." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [], "text": "any" }, "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.", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "evidence": [ { "source": "us-ach:src.bmo-ach-return-reason-codes-2025-05" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-2-banking-days", "evidence": [ { "source": "us-ach:src.bmo-ach-return-reason-codes-2025-05" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R11", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R03", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R04", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R06", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.bmo-ach-return-reason-codes-2025-05", "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R23", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R24", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R18", "id": "R18", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not resend unchanged. Correct the effective entry date and originate the entry again." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [], "text": "any" }, "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].", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.ach-operator", "evidence": [ { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-operator-reject", "evidence": [ { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R19", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R25", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R19", "id": "R19", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not resend unchanged. Correct the amount field and originate the entry again." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [], "text": "any" }, "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].", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.ach-operator", "evidence": [ { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-operator-reject", "evidence": [ { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R18", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R25", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R26", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R20", "id": "R20", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not retry to the same account. Collect a transaction account and originate fresh." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [], "text": "any" }, "caveat": null, "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-2-banking-days", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R02", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.fhb-ach-return-reason-codes", "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.limits-ach-debits-to-a-savings-account", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.participants-a-wrong-account-type-code-is-corrected-not-refused", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R35", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R21", "id": "R21", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not retry until the identification value is corrected with your ODFI. The same header produces the same return." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [], "text": "CIE and others" }, "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.", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-2-banking-days", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.fhb-ach-return-reason-codes", "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R22", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R22", "id": "R22", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not resend unchanged. Correct the identification number, then originate a new entry." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [ "us-ach:txn.cie", "us-ach:txn.mte" ], "excludes": [], "text": "CIE, MTE" }, "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]", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-2-banking-days", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.cie", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.mte", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R21", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.fhb-ach-return-reason-codes", "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R44", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R23", "id": "R23", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [], "excludes": [], "text": "credit entries, consumer or non-consumer" }, "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.", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-refused-credit", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R17", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R06", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:R24", "id": "R24", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not resend unless you have confirmed the returned entry was not a duplicate and the amount is still owed." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [], "text": "any" }, "caveat": "Public bank guides advise RDFIs to use R24 with care because the originator may already have reversed a duplicated file. [Unverified]", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-2-banking-days", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R06", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R17", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.fhb-ach-return-reason-codes", "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R47", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R25", "id": "R25", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not resend unchanged. Correct the addenda and originate the entry again." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [], "text": "any" }, "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].", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.ach-operator", "evidence": [ { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-operator-reject", "evidence": [ { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R18", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R19", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.format-addenda-indicator-and-linking", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R26", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R27", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R26", "id": "R26", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not resend unchanged. Correct the field and originate the entry again." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [], "text": "any" }, "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].", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.ach-operator", "evidence": [ { "source": "us-ach:src.bmo-ach-return-reason-codes-2025-05" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-operator-reject", "evidence": [ { "source": "us-ach:src.bmo-ach-return-reason-codes-2025-05" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R25", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R19", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.bmo-ach-return-reason-codes-2025-05", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.format-mandatory-required-optional-fields", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R27", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R28", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R27", "id": "R27", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not resend unchanged. Correct the trace number and send the entry again." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [], "text": "any, including returns and Notifications of Change" }, "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].", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.ach-operator", "evidence": [ { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-operator-reject", "evidence": [ { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R25", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R26", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.format-addenda-indicator-and-linking", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-return-entry-construction", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.format-trace-number-assignment", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R28", "id": "R28", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not resend unchanged. Correct the routing number and originate the entry again." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [], "text": "any" }, "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].", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.ach-operator", "evidence": [ { "source": "us-ach:src.bmo-ach-return-reason-codes-2025-05" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-operator-reject", "evidence": [ { "source": "us-ach:src.bmo-ach-return-reason-codes-2025-05" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R26", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.bmo-ach-return-reason-codes-2025-05", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R13", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R42", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R29", "id": "R29", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not retry. Resolve the authorization question in writing before any further entry." }, "applies_to": { "direction": "debit", "account_type": "non_consumer", "transaction_types": [ "us-ach:txn.ccd", "us-ach:txn.ctx" ], "excludes": [], "text": "CCD, CTX" }, "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.", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-2-banking-days", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.no-reinitiation-without-new-authorization", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.unauthorized-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.ccd", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.ctx", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R10", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R05", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.fhb-ach-return-reason-codes", "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:mandate.corporate-debit-agreement", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.return-what-a-blocked-debit-comes-back-as", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R05", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R10", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R31", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R51", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R30", "id": "R30", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not resend the same truncated entry to the same institution. Its non-participation does not change between presentments." }, "applies_to": { "direction": "debit", "account_type": "any", "transaction_types": [ "us-ach:txn.trc", "us-ach:txn.trx" ], "excludes": [], "text": "TRC, TRX debit" }, "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]", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.ach-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-next-file-delivery", "note": "[Unverified] Carried from the code record, which marks this window as not confirmed.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.trc", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.trx", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R11", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:R31", "id": "R31", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not retry until the underlying reason is resolved with the receiver in writing." }, "applies_to": { "direction": "any", "account_type": "non_consumer", "transaction_types": [ "us-ach:txn.ccd", "us-ach:txn.ctx" ], "excludes": [], "text": "CCD, CTX" }, "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]", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-late-by-agreement", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.ccd", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.ctx", "evidence": [ { "source": "us-ach:src.fhb-ach-return-reason-codes" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R29", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.fhb-ach-return-reason-codes", "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R06", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R68", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R70", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R32", "id": "R32", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [], "text": "any entry, credit or debit" }, "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]", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.ach-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-next-file-delivery", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R34", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R33", "id": "R33", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not resend the item as XCK. The receiving institution has already exercised its discretion on it." }, "applies_to": { "direction": "debit", "account_type": "any", "transaction_types": [ "us-ach:txn.xck" ], "excludes": [], "text": "XCK debit" }, "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]", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "evidence": [ { "source": "us-ach:src.bmo-ach-return-reason-codes-2025-05" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-60-calendar-days", "evidence": [ { "source": "us-ach:src.bmo-ach-return-reason-codes-2025-05" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.xck", "evidence": [ { "source": "us-ach:src.bmo-ach-return-reason-codes-2025-05" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null } ], "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": "us-ach:src.bmo-ach-return-reason-codes-2025-05", "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:R34", "id": "R34", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [], "text": "any entry, credit or debit" }, "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]", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.ach-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-next-file-delivery", "note": "[Unverified] Carried from the code record, which marks this window as not confirmed.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R32", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:R35", "id": "R35", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not resend to the same account. Obtain an eligible account and correct the transaction code first." }, "applies_to": { "direction": "debit", "account_type": "any", "transaction_types": [], "excludes": [], "text": "debits to loan accounts; CIE debits; reversals excepted" }, "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].", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.ach-operator", "evidence": [ { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-operator-reject", "evidence": [ { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R20", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R36", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R36", "id": "R36", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "credit", "account_type": "any", "transaction_types": [ "us-ach:txn.arc", "us-ach:txn.boc", "us-ach:txn.pop", "us-ach:txn.rck", "us-ach:txn.tel", "us-ach:txn.xck" ], "excludes": [], "text": "credits under ARC, BOC, POP, RCK, TEL, XCK; reversals excepted" }, "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]", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.ach-operator", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-operator-reject", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.arc", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.boc", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.pop", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.rck", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.tel", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.xck", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R35", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:R37", "id": "R37", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not resend the entry. The item has already been paid once." }, "applies_to": { "direction": "debit", "account_type": "any", "transaction_types": [ "us-ach:txn.arc", "us-ach:txn.boc", "us-ach:txn.pop" ], "excludes": [], "text": "ARC, BOC, POP debit" }, "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]", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "evidence": [ { "source": "us-ach:src.bmo-ach-return-reason-codes-2025-05" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-60-calendar-days", "evidence": [ { "source": "us-ach:src.bmo-ach-return-reason-codes-2025-05" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.written-statement-of-unauthorized-debit", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.arc", "evidence": [ { "source": "us-ach:src.bmo-ach-return-reason-codes-2025-05" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.boc", "evidence": [ { "source": "us-ach:src.bmo-ach-return-reason-codes-2025-05" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.pop", "evidence": [ { "source": "us-ach:src.bmo-ach-return-reason-codes-2025-05" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R39", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R38", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R11", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.bmo-ach-return-reason-codes-2025-05", "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R53", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R38", "id": "R38", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not reconvert or resend the same check. Get a new payment from the payer." }, "applies_to": { "direction": "debit", "account_type": "any", "transaction_types": [ "us-ach:txn.arc", "us-ach:txn.boc" ], "excludes": [], "text": "ARC, BOC debit" }, "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]", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "evidence": [ { "source": "us-ach:src.bmo-ach-return-reason-codes-2025-05" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-60-calendar-days", "evidence": [ { "source": "us-ach:src.bmo-ach-return-reason-codes-2025-05" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.arc", "evidence": [ { "source": "us-ach:src.bmo-ach-return-reason-codes-2025-05" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.boc", "evidence": [ { "source": "us-ach:src.bmo-ach-return-reason-codes-2025-05" }, { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R08", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R39", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.bmo-ach-return-reason-codes-2025-05", "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R37", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R52", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R39", "id": "R39", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "debit", "account_type": "any", "transaction_types": [ "us-ach:txn.arc", "us-ach:txn.boc", "us-ach:txn.pop" ], "excludes": [], "text": "ARC, BOC, POP debit" }, "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]", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "evidence": [ { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-2-banking-days", "evidence": [ { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.arc", "evidence": [ { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.boc", "evidence": [ { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.pop", "evidence": [ { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R11", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R10", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R37", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R38", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R40", "id": "R40", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not resend the ENR to the same agency. Use another enrollment method." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [ "us-ach:txn.enr" ], "excludes": [], "text": "ENR (automated enrollment) entries only" }, "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]", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.federal-government-agency", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-enr-agency", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.enr", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.format-enr-entry-codes", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R41", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R42", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R43", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R44", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R45", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R46", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R47", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R41", "id": "R41", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not resend unchanged. Correct the transaction code, then send a new ENR, or enroll another way." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [ "us-ach:txn.enr" ], "excludes": [], "text": "ENR (automated enrollment) entries only" }, "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]", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.federal-government-agency", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-enr-agency", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.enr", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R40", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.format-enr-entry-codes", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R42", "id": "R42", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not resend unchanged. Correct the routing number and check digit, then send a new ENR, or enroll another way." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [ "us-ach:txn.enr" ], "excludes": [], "text": "ENR (automated enrollment) entries only" }, "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]", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.federal-government-agency", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-enr-agency", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.enr", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R28", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R13", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R40", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:R43", "id": "R43", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not resend unchanged. Correct the account number, then send a new ENR, or enroll another way." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [ "us-ach:txn.enr" ], "excludes": [], "text": "ENR (automated enrollment) entries only" }, "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]", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.federal-government-agency", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-enr-agency", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.enr", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R04", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R03", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R40", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:R44", "id": "R44", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not resend unchanged. Correct the identification number and uppercase the record, then send a new ENR, or enroll another way." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [ "us-ach:txn.enr" ], "excludes": [], "text": "ENR (automated enrollment) entries only" }, "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]", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.federal-government-agency", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-enr-agency", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.enr", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R22", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R40", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R45", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R45", "id": "R45", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not resend unchanged. Correct the name and uppercase the record, then send a new ENR, or enroll another way." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [ "us-ach:txn.enr" ], "excludes": [], "text": "ENR (automated enrollment) entries only" }, "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]", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.federal-government-agency", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-enr-agency", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.enr", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R44", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R40", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:R46", "id": "R46", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not resend unchanged. Correct the representative payee indicator, then send a new ENR, or enroll another way." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [ "us-ach:txn.enr" ], "excludes": [], "text": "ENR (automated enrollment) entries only" }, "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]", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.federal-government-agency", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-enr-agency", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.enr", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R14", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R40", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:R47", "id": "R47", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not resend. Confirm with the agency whether the original enrollment was accepted." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [ "us-ach:txn.enr" ], "excludes": [], "text": "ENR (automated enrollment) entries only" }, "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]", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.federal-government-agency", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-enr-agency", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.enr", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R24", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R40", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": [] }, "source_class": null, "effective_status": "draft", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:R50", "id": "R50", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "debit", "account_type": "any", "transaction_types": [ "us-ach:txn.rck" ], "excludes": [], "text": "RCK debit" }, "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.", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-2-banking-days", "evidence": [ { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "note": "[Unverified] Carried from the code record, which marks this window as not confirmed.", "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.rck", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R51", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R52", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R53", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R51", "id": "R51", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "debit", "account_type": "any", "transaction_types": [ "us-ach:txn.rck" ], "excludes": [], "text": "RCK debit" }, "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.", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-60-calendar-days", "evidence": [ { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.written-statement-of-unauthorized-debit", "evidence": [ { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.unauthorized-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.rck", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R52", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R53", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R50", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R10", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R29", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:R52", "id": "R52", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not resend the RCK entry. Collect through other means, subject to the stop order and any dispute." }, "applies_to": { "direction": "debit", "account_type": "any", "transaction_types": [ "us-ach:txn.rck" ], "excludes": [], "text": "RCK debit" }, "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]", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-60-calendar-days", "evidence": [ { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.rck", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R08", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R38", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R50", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R51", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R53", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R53", "id": "R53", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not resend the RCK entry. The check has been presented through another channel." }, "applies_to": { "direction": "debit", "account_type": "any", "transaction_types": [ "us-ach:txn.rck" ], "excludes": [], "text": "RCK debit" }, "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]", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-60-calendar-days", "evidence": [ { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.written-statement-of-unauthorized-debit", "evidence": [ { "source": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "counts_toward", "to": "us-ach:rule.overall-return-rate-threshold", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.rck", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R37", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R52", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R50", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R51", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R61", "id": "R61", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [ "us-ach:txn.iat" ], "text": "every SEC code except IAT" }, "caveat": "The public guides read describe the code but not how the misrouted return is then re-sent; that step is [Unverified].", "relations": [ { "type": "raised_in", "to": "us-ach:exc.dishonored-return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.dishonor-window-5-banking-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.dishonor-codes-exclude-iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R71", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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": "us-ach:src.commerce-bank-ach-return-noc-tran-codes-2022-11", "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": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "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": "us-ach:src.bank-of-north-dakota-ach-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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.format-dishonored-return-addenda", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R71", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R62", "id": "R62", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [ "us-ach:txn.iat" ], "text": "every SEC code except IAT" }, "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]", "relations": [ { "type": "raised_in", "to": "us-ach:exc.dishonored-return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.dishonor-window-5-banking-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.dishonor-codes-exclude-iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R77", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.recall-what-a-reversal-may-be-used-for", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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": "us-ach:src.commerce-bank-ach-return-noc-tran-codes-2022-11", "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": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "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": "us-ach:src.bank-of-north-dakota-ach-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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R77", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R67", "id": "R67", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [ "us-ach:txn.iat" ], "text": "every SEC code except IAT" }, "caveat": null, "relations": [ { "type": "raised_in", "to": "us-ach:exc.dishonored-return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.dishonor-window-5-banking-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.dishonor-codes-exclude-iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R75", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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": "us-ach:src.commerce-bank-ach-return-noc-tran-codes-2022-11", "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": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "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": "us-ach:src.bank-of-north-dakota-ach-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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R75", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R68", "id": "R68", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [ "us-ach:txn.iat" ], "text": "every SEC code except IAT" }, "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]", "relations": [ { "type": "raised_in", "to": "us-ach:exc.dishonored-return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.dishonor-window-5-banking-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.dishonor-codes-exclude-iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R73", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R31", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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": "us-ach:src.commerce-bank-ach-return-noc-tran-codes-2022-11", "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": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "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": "us-ach:src.bank-of-north-dakota-ach-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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R73", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R69", "id": "R69", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [ "us-ach:txn.iat" ], "text": "every SEC code except IAT" }, "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.", "relations": [ { "type": "raised_in", "to": "us-ach:exc.dishonored-return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.dishonor-window-5-banking-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.dishonor-codes-exclude-iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R74", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R76", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.return-returns-can-be-sent-back-again", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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": "us-ach:src.commerce-bank-ach-return-noc-tran-codes-2022-11", "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": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "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": "us-ach:src.bank-of-north-dakota-ach-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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.format-dishonored-return-addenda", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R74", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R76", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R70", "id": "R70", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [ "us-ach:txn.iat" ], "text": "every SEC code except IAT" }, "caveat": "The guides read list no contest code that answers R70 directly. [Inference]", "relations": [ { "type": "raised_in", "to": "us-ach:exc.dishonored-return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.dishonor-window-5-banking-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.dishonor-codes-exclude-iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R06", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R31", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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": "us-ach:src.commerce-bank-ach-return-noc-tran-codes-2022-11", "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": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "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": "us-ach:src.bank-of-north-dakota-ach-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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:R71", "id": "R71", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [ "us-ach:txn.iat" ], "text": "every SEC code except IAT" }, "caveat": null, "relations": [ { "type": "raised_in", "to": "us-ach:exc.contested-dishonored-return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.contest-window-2-banking-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.contested-dishonor-ends-the-network-dispute", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.dishonor-codes-exclude-iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R61", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "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": "us-ach:src.bank-of-north-dakota-ach-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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R61", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R72", "id": "R72", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [ "us-ach:txn.iat" ], "text": "every SEC code except IAT" }, "caveat": null, "relations": [ { "type": "raised_in", "to": "us-ach:exc.contested-dishonored-return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.contest-window-2-banking-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.contested-dishonor-ends-the-network-dispute", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.dishonor-codes-exclude-iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.dishonor-window-5-banking-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "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": "us-ach:src.bank-of-north-dakota-ach-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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [] }, { "uid": "us-ach:R73", "id": "R73", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [ "us-ach:txn.iat" ], "text": "every SEC code except IAT" }, "caveat": null, "relations": [ { "type": "raised_in", "to": "us-ach:exc.contested-dishonored-return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.contest-window-2-banking-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.contested-dishonor-ends-the-network-dispute", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.dishonor-codes-exclude-iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R68", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "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": "us-ach:src.bank-of-north-dakota-ach-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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R68", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R74", "id": "R74", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [ "us-ach:txn.iat" ], "text": "every SEC code except IAT" }, "caveat": "R74 is how a return with bad data is repaired, rather than sending a new return. [Inference]", "relations": [ { "type": "raised_in", "to": "us-ach:exc.contested-dishonored-return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.contest-window-2-banking-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.contested-dishonor-ends-the-network-dispute", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.dishonor-codes-exclude-iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R69", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R76", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "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": "us-ach:src.bank-of-north-dakota-ach-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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R69", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R76", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R75", "id": "R75", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [ "us-ach:txn.iat" ], "text": "every SEC code except IAT" }, "caveat": null, "relations": [ { "type": "raised_in", "to": "us-ach:exc.contested-dishonored-return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.contest-window-2-banking-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.contested-dishonor-ends-the-network-dispute", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.dishonor-codes-exclude-iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R67", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "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": "us-ach:src.bank-of-north-dakota-ach-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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R67", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R76", "id": "R76", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [ "us-ach:txn.iat" ], "text": "every SEC code except IAT" }, "caveat": null, "relations": [ { "type": "raised_in", "to": "us-ach:exc.contested-dishonored-return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.contest-window-2-banking-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.contested-dishonor-ends-the-network-dispute", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.dishonor-codes-exclude-iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R69", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R74", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "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": "us-ach:src.bank-of-north-dakota-ach-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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R69", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R74", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R77", "id": "R77", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [ "us-ach:txn.iat" ], "text": "every SEC code except IAT" }, "caveat": null, "relations": [ { "type": "raised_in", "to": "us-ach:exc.contested-dishonored-return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.contest-window-2-banking-days", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.contested-dishonor-ends-the-network-dispute", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.dishonor-codes-exclude-iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R62", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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": "us-ach:src.jefferson-bank-obligations-of-originators-2022-03", "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": "us-ach:src.bank-of-north-dakota-ach-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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:R62", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R80", "id": "R80", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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]." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [ "us-ach:txn.iat" ], "excludes": [], "text": "outbound IAT, returned by the Gateway" }, "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.", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.gateway", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-2-banking-days", "note": "[Unverified] CBS Bank's guide gives the 2 banking day window; BMO's lists no time frame for the Gateway codes.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.iat-foreign-exchange-fields", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.iat-gateway-only-return-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.iat-foreign-exchange-fields", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-gateway-only-return-codes", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R81", "id": "R81", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not resend to the same Gateway until an IAT agreement exists; once it does, a new entry may be sent [Inference]." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [ "us-ach:txn.iat" ], "excludes": [], "text": "outbound IAT, returned by the Gateway" }, "caveat": "For Gateway use on outbound IAT only.", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.gateway", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-2-banking-days", "note": "[Unverified] CBS Bank's guide gives the 2 banking day window; BMO's lists no time frame for the Gateway codes.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.iat-gateway-agreement-with-odfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.iat-gateway-only-return-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.iat-gateway-agreement-with-odfi", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-gateway-only-return-codes", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R82", "id": "R82", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Resend once the foreign bank identifier is corrected [Inference]." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [ "us-ach:txn.iat" ], "excludes": [], "text": "outbound IAT, returned by the Gateway" }, "caveat": "For Gateway use on outbound IAT only.", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.gateway", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-2-banking-days", "note": "[Unverified] CBS Bank's guide gives the 2 banking day window; BMO's lists no time frame for the Gateway codes.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.iat-gateway-only-return-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.iat-gateway-only-return-codes", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R83", "id": "R83", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "A new entry may be sent once the Gateway confirms the settlement problem is resolved [Inference]." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [ "us-ach:txn.iat" ], "excludes": [], "text": "outbound IAT, returned by the Gateway" }, "caveat": "For Gateway use on outbound IAT only.", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.gateway", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-2-banking-days", "note": "[Unverified] CBS Bank's guide gives the 2 banking day window; BMO's lists no time frame for the Gateway codes.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.iat-return-amount-may-differ", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.iat-gateway-only-return-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.iat-gateway-only-return-codes", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R84", "id": "R84", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Do not resend the same entry through the same Gateway; the Gateway declined it at its discretion." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [ "us-ach:txn.iat" ], "excludes": [], "text": "outbound IAT, returned by the Gateway" }, "caveat": "For Gateway use on outbound IAT only. BMO's guide gives only the excessive risk ground.", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.gateway", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-2-banking-days", "note": "[Unverified] CBS Bank's guide gives the 2 banking day window; BMO's lists no time frame for the Gateway codes.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "applies_to", "to": "us-ach:txn.iat", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.iat-prenotes", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.iat-reversal-best-effort", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.iat-gateway-only-return-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.iat-gateway-only-return-codes", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R85", "id": "R85", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "Resend as a properly formatted IAT, not under the same domestic code [Inference]." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [ "us-ach:txn.iat" ], "text": "an entry under a domestic SEC code that is really an outbound international payment" }, "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.", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.gateway", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-2-banking-days", "note": "[Unverified] CBS Bank's guide gives the 2 banking day window; BMO's lists no time frame for the Gateway codes.", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.iat-definition", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:rule.iat-gateway-only-return-codes", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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." } ] }, "source_class": "secondary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.iat-gateway-only-return-codes", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "uid": "us-ach:R90", "id": "R90", "rail": "us-ach", "class": "ReasonCode", "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, "guidance": "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]." }, "applies_to": { "direction": "any", "account_type": "any", "transaction_types": [], "excludes": [], "text": "any" }, "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.", "relations": [ { "type": "raised_in", "to": "us-ach:exc.return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.rdfi", "evidence": [ { "source": "us-ach:src.nacha-sanctions-compliance-return-code" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "returned_by", "to": "us-ach:role.gateway", "evidence": [ { "source": "us-ach:src.nacha-sanctions-compliance-return-code" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "governed_by", "to": "us-ach:rule.return-window-sanctions-determination", "evidence": [ { "source": "us-ach:src.nacha-sanctions-compliance-return-code" } ], "status": "corroborated", "effective_status": "corroborated", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:R16", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.nacha-sanctions-compliance-return-code", "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." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.decision-points-what-a-false-positive-is-on-a-sanctions-screen", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.iat-ofac-hold-before-posting", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:rule.participants-who-screens-a-domestic-entry-for-sanctions", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:R16", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "us-ach:rule.consumer-law-what-is-covered", "us-ach:rule.consumer-law-authorisation-for-a-recurring-debit-must-be", "us-ach:rule.consumer-law-the-stop-payment-right", "us-ach:rule.consumer-law-warning-when-the-amount-changes", "us-ach:rule.consumer-law-notice-that-an-incoming-credit-arrived", "us-ach:rule.consumer-law-credit-as-of-the-day-funds-arrive", "us-ach:rule.consumer-law-the-error-clock", "us-ach:rule.liability-the-consumers-exposure-is-capped", "us-ach:rule.consumer-law-no-forcing-a-consumer-onto-the-rail", "us-ach:rule.consumer-law-government-benefit-accounts-are-inside-the", "us-ach:rule.refund-why-95-days-and-not-60" ], "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.", "relations": [ { "type": "see_also", "to": "us-ach:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:decision-points", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.reg-e-12-cfr-1005", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:decision-points", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:finality", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:liability", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:refund", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:return", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "us-ach:rule.decision-points-whether-to-honour-a-request-to-return", "us-ach:rule.recall-the-receiving-side-is-not-obliged-to-fund-it", "us-ach:rule.decision-points-whether-a-reversal-was-proper", "us-ach:rule.finality-settlement-can-also-be-refused-before-it-happens", "us-ach:rule.settlement-credit-given-for-a-debit-is-not-the-same-as", "us-ach:rule.settlement-prefunding-where-a-reserve-bank-requires-it", "us-ach:rule.decision-points-where-to-set-the-fraud-thresholds", "us-ach:rule.decision-points-whether-a-consumers-claim-is-an-error", "us-ach:rule.consumer-law-the-stop-payment-right", "us-ach:rule.decision-points-whether-an-entry-breaches-sanctions-obligations", "us-ach:rule.decision-points-whether-to-dispute-a-return", "us-ach:rule.decision-points-whether-a-description-is-true", "us-ach:rule.decision-points-whether-the-originator-keeps-its-access", "us-ach:rule.decision-points-whether-funds-appear-before-settlement" ], "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.", "relations": [ { "type": "see_also", "to": "us-ach:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:consumer-law", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:participants", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.frb-operating-circular-4-2026-01-05", "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": "us-ach:src.nacha-reversals-and-enforcement", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:consumer-law", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:finality", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:liability", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:participants", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:recall", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:refund", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:return", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:settlement", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "us-ach:rule.finality-the-moment-settlement-is-final-for-a-credit", "us-ach:rule.settlement-credit-given-for-a-debit-is-not-the-same-as", "us-ach:rule.finality-settlement-can-be-unwound-the-next-morning", "us-ach:rule.finality-settlement-can-also-be-refused-before-it-happens", "us-ach:rule.finality-no-recall-by-the-sender-once-the-file-has-gone", "us-ach:rule.finality-second-layer-article-4a-and-only-for-some", "us-ach:rule.finality-ach-is-not-a-fedwire-funds-transfer-and", "us-ach:rule.finality-third-layer-the-consumers-claim-runs-on-its-own", "us-ach:rule.finality-the-practical-window-returns-run-in-days-not", "us-ach:rule.finality-reversals-exist-and-they-are-new-entries" ], "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.", "relations": [ { "type": "see_also", "to": "us-ach:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:hours", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:consumer-law", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:decision-points", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.frb-operating-circular-4-2026-01-05", "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": "us-ach:src.reg-j-12-cfr-210", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:rule.return-what-a-processor-calls-a-late-return", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:consumer-law", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:decision-points", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:hours", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:liability", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:limits", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:participants", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:recall", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:refund", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:return", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:settlement", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "us-ach:rule.hours-what-a-banking-day-is", "us-ach:rule.hours-same-day-transmission-deadlines", "us-ach:rule.hours-overnight-windows-for-future-dated-work", "us-ach:rule.hours-return-deadlines-follow-the-same-clock", "us-ach:rule.hours-release-not-transmission-is-what-counts", "us-ach:rule.hours-how-long-the-network-is-open", "us-ach:rule.hours-when-the-receiver-can-use-the-money", "us-ach:rule.hours-one-geographic-exception-to-that-availability", "us-ach:rule.hours-industry-practice-around-weekends" ], "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.", "relations": [ { "type": "see_also", "to": "us-ach:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:limits", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.frb-operating-circular-4-2026-01-05", "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": "us-ach:src.fedach-processing-schedule-2022-09-12", "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": "us-ach:src.nacha-funds-availability-non-same-day-credits", "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)." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:finality", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:limits", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:return", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:settlement", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "us-ach:rule.liability-the-consumers-exposure-is-capped", "us-ach:rule.liability-the-60-day-line-on-a-statement", "us-ach:rule.liability-the-warranty-that-carries-loss-back-to-the", "us-ach:rule.request-for-return-indemnity", "us-ach:rule.liability-the-operators-liability-and-what-it-is-not", "us-ach:rule.liability-how-damages-against-the-operator-are-measured", "us-ach:rule.liability-article-4a-credits-are-a-separate-regime", "us-ach:rule.liability-two-deadlines-that-quietly-destroy-claims", "us-ach:rule.liability-banks-indemnify-the-operator-not-the-other-way", "us-ach:rule.liability-fraud-duties-are-monitoring-duties-not-a-loss", "us-ach:rule.liability-settlement-risk-sits-with-the-reserve-banks" ], "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.", "relations": [ { "type": "see_also", "to": "us-ach:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:consumer-law", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:participants", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:decision-points", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.frb-operating-circular-4-2026-01-05", "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": "us-ach:src.nacha-limitation-on-warranty-claims", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "au-npp:liability", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "uk-fps:liability", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:consumer-law", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:decision-points", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:finality", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:participants", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:refund", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:return", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "us-ach:rule.limits-the-same-day-ach-ceiling-today", "us-ach:rule.limits-the-ceiling-that-is-coming", "us-ach:rule.limits-how-the-operator-sees-the-limit", "us-ach:rule.limits-eligibility-limits-not-just-dollar-limits", "us-ach:rule.limits-other-dollar-limits-exist-and-are-not-published", "us-ach:rule.limits-no-published-ceiling-on-non-same-day-entries", "us-ach:rule.limits-the-limit-a-sender-actually-hits", "us-ach:rule.limits-funding-capacity-can-act-as-a-limit" ], "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.", "relations": [ { "type": "see_also", "to": "us-ach:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:hours", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:participants", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.nacha-same-day-ach-limit-10-million", "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": "us-ach:src.frb-operating-circular-4-2026-01-05", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:hours", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:messages", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:participants", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:settlement", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "us-ach:rule.messages-the-record-line", "us-ach:rule.messages-the-record-types-a-payment-uses", "us-ach:rule.messages-who-defines-the-format", "us-ach:rule.messages-the-standard-entry-class-code", "us-ach:rule.messages-traffic-that-moves-no-money", "us-ach:rule.messages-correcting-the-data-rather-than-the-payment", "us-ach:rule.messages-the-description-field-is-becoming-meaningful", "us-ach:rule.messages-reversal-is-a-field-value-not-a-message-type", "us-ach:rule.messages-what-identifies-an-entry-afterwards", "us-ach:rule.messages-character-handling-is-not-uniform-between" ], "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.", "relations": [ { "type": "see_also", "to": "us-ach:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:limits", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:participants", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.nacha-currently-accepted-characters", "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": "us-ach:src.frb-operating-circular-4-2026-01-05", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:hours", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:limits", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:participants", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:recall", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:return", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "us-ach:rule.participants-the-five-roles", "us-ach:rule.participants-there-are-two-operators-not-one", "us-ach:rule.participants-who-counts-as-a-bank-for-fedach", "us-ach:rule.participants-the-entry-condition-is-a-settlement-account", "us-ach:rule.participants-a-correspondents-account-can-be-used-and-it", "us-ach:rule.participants-agents-are-allowed-and-the-bank-still-owns-the", "us-ach:rule.participants-third-party-senders-including-nested-ones", "us-ach:rule.participants-new-duties-reach-originators-and-service", "us-ach:rule.participants-receiving-is-an-agreement-too", "us-ach:rule.participants-the-sanction-for-breaking-the-rules", "us-ach:rule.participants-scale-for-context" ], "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.", "relations": [ { "type": "see_also", "to": "us-ach:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:limits", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:decision-points", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.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": "us-ach:src.frb-operating-circular-4-2026-01-05", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:decision-points", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:liability", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:limits", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:messages", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:settlement", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "us-ach:rule.finality-no-recall-by-the-sender-once-the-file-has-gone", "us-ach:rule.recall-what-a-reversal-may-be-used-for", "us-ach:rule.recall-the-two-clocks-on-a-reversal", "us-ach:rule.recall-how-a-reversal-must-be-formatted", "us-ach:rule.recall-the-receiving-side-is-not-obliged-to-fund-it", "us-ach:rule.recall-a-wrongly-used-reversal-can-be-sent-back", "us-ach:rule.recall-reversing-a-whole-file", "us-ach:rule.recall-asking-rather-than-reversing", "us-ach:rule.recall-the-operator-has-its-own-cancellation-power", "us-ach:rule.recall-before-the-file-leaves-it-is-a-different" ], "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.", "relations": [ { "type": "see_also", "to": "us-ach:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:decision-points", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.nacha-reversals-and-enforcement", "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": "us-ach:src.popular-bank-ach-rules-awareness-guide-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." } ] }, "source_class": "public_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:decision-points", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:finality", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:messages", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:refund", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:return", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "us-ach:rule.refund-the-consumers-statutory-route", "us-ach:rule.refund-provisional-credit-while-the-bank-investigates", "us-ach:rule.refund-longer-clocks-for-new-accounts-and-some", "us-ach:rule.consumer-law-the-stop-payment-right", "us-ach:rule.refund-the-ach-tool-that-carries-the-money-back", "us-ach:rule.liability-the-warranty-that-carries-loss-back-to-the", "us-ach:rule.refund-why-95-days-and-not-60", "us-ach:rule.refund-a-business-has-no-equivalent-right", "us-ach:rule.refund-a-merchant-refund-is-a-new-payment", "us-ach:rule.refund-federal-payments-have-their-own-recovery-route" ], "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.", "relations": [ { "type": "see_also", "to": "us-ach:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:consumer-law", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:decision-points", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.reg-e-12-cfr-1005", "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": "us-ach:src.nacha-limitation-on-warranty-claims", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:consumer-law", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:decision-points", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:finality", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:liability", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:recall", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:return", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "us-ach:rule.return-the-mechanism", "us-ach:rule.return-how-a-return-settles", "us-ach:rule.return-window-2-banking-days", "us-ach:rule.return-window-60-calendar-days", "us-ach:rule.return-what-the-consumer-has-to-sign", "us-ach:rule.return-returns-can-be-sent-back-again", "us-ach:rule.return-disputing-a-return-through-the-operator", "us-ach:rule.return-re-presenting-a-failed-debit", "us-ach:rule.return-an-adjustment-path-exists-alongside-the-return", "us-ach:rule.return-a-new-return-code-with-its-own-window-is-dated" ], "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.", "relations": [ { "type": "see_also", "to": "us-ach:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:settlement", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:hours", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:recall", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:refund", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:liability", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:messages", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:decision-points", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:consumer-law", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.nacha-reversals-and-enforcement", "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": "us-ach:src.frb-operating-circular-4-2026-01-05", "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": "us-ach:src.cbs-bank-ach-return-reason-codes-2025-03", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:consumer-law", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:decision-points", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:finality", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:hours", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:liability", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:messages", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:recall", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:refund", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:settlement", "type": "see_also", "status": "draft", "effective_status": "draft" } ] }, { "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.", "rules": [ "us-ach:rule.settlement-what-settlement-is", "us-ach:rule.settlement-whose-obligation-it-is", "us-ach:rule.settlement-same-day-settlement-clock-times", "us-ach:rule.settlement-future-dated-settlement-clock-time", "us-ach:rule.settlement-which-day-is-the-settlement-day", "us-ach:rule.settlement-effective-date-windows-are-bounded", "us-ach:rule.settlement-the-settlement-asset-and-its-hours", "us-ach:rule.settlement-credit-given-for-a-debit-is-not-the-same-as", "us-ach:rule.settlement-prefunding-where-a-reserve-bank-requires-it", "us-ach:rule.return-how-a-return-settles" ], "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.", "relations": [ { "type": "see_also", "to": "us-ach:finality", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:hours", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:limits", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:return", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:participants", "status": "draft", "effective_status": "draft", "effective_status_reason": null }, { "type": "see_also", "to": "us-ach:decision-points", "status": "draft", "effective_status": "draft", "effective_status_reason": null } ], "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": "us-ach:src.frb-operating-circular-4-2026-01-05", "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": "us-ach:src.fedach-processing-schedule-2022-09-12", "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." } ] }, "source_class": "authoritative_primary", "effective_status": "corroborated", "effective_status_reason": null, "used_by": [ { "from": "us-ach:decision-points", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:finality", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:hours", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:liability", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:limits", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:messages", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:participants", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:recall", "type": "see_also", "status": "draft", "effective_status": "draft" }, { "from": "us-ach:return", "type": "see_also", "status": "draft", "effective_status": "draft" } ] } ] }